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PREFACE 


In March 1955, Col. M. B. Chatfield of the Army 
Ordnance Missile Defense Command at Redstone Arsenal 
asked Bell Laboratories to carry out an 18-month study of 
defense against future air threats including Intercontinental 
Ballistic Missiles (ICBMs), then in early development in 
the United States. This history begins with that study and 
highlights the evolution of ABM defense during the ensuing 
twenty years that led to a tactical operating ABM defense 
system at Grand Forks, North Dakota. 


It covers the important decisions, changing require- 
ments, and major innovative development steps taken to 
meet the changing threat. The research and development 
programs associated with each major ABM system are dis- 
cussed together with the principal radar, missile, andcom- 
puter subsystems. The report concludes with a summary 
of lessons learned with respect to managing such programs 
in the future and includes a comprehensive bibliography of 
supporting reference material. 
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PREFACE 


In March 1955, Col. M. B. Chatfield of the Army 
Ordnance Missile Defense Command at Redstone Arsenal 
asked Bell Laboratories to carry out an 18-month study of 
defense against future air threats including Intercontinental 
Ballistic Missiles (ICBMs), then in early development in 
the United States. This history begins with that study and 
highlights the evolution of ABM defense during the ensuing 
twenty years that led to a tactical operating ABM defense 
system at Grand Forks, North Dakota. 


It covers the important decisions, changing require- 
ments, and major innovative development steps taken to 
meet the changing threat. The research and development 
programs associated with each major ABM system are dis- 
cussed together with the principal radar, missile, andcom- 
puter subsystems. The report concludes with a summary 
of lessons learned with respect to managing such programs 
in the future and includes a comprehensive bibliography of 
supporting reference material. 


iii 





pr ecaen Pie een Pate St Pognle 4S) Se aey ey 





y oer 













Rpermer hard 


vitae 


CONTENTS 


Part I. HISTORY OF ABM DEVELOPMENT 


NIKE. TESTUDY. si.c5 26:20, a6 te en eee xe Be Jars ee ed! ie OR Rea we RE 


ABM Defense Requirements... 2... 2. 2s ese e ree eee nner ene 
Additional Defense Considerations .........-.ee0ce0c ee eae vate 
Proposed ABM System ........++000e0. ease ie en" ce Ge bepel axe 
Results of NIKE II Study. . 2... 2 we we ewe ewe we we ee te te es 
AIC BM Report ose) ie ice he ee eee We es OS a ce ea a ee See os 


AICBM DEVELOPMENT CONTRACT — NIKE II/NIKE-ZEUS ......--2+.6s 


Discrimination Radar .. 1... ee eee ew wr wee ew wee we tem eee ne 
Acquisition Radar ..... siglat domio Satie” Spec} “outa ar e-Cetah ae eis canta Maite v6 ae 
ZEUS Missile .. 1. 2 2 www weer ee err eee reve oe ee ceo 
Further Meetings on NIKE-ZEUS System... 2... 2 ee eee erence eer ve 


FIELD TESTING THE NIKE-ZEUS SYSTEM. ... 2... ee eee cece eee 


HIGHLIGHTS OF NIKE-ZEUS R&D TEST RESULTS. ......-..0.2200-6 


ZEUS Missile Tests: 25.6. 30 02 :8e 6s 6) et Fe Beles Welw Sel ses Ow ee Sg A 
TTR-Whippany/Ascension. ......-e-+ee8. oh an tds Se Ted tv eines we karehs 
White Sands Missile Range Tests... 1... ee ew eee eee rer ee een 
NIKE- ZEUS System Tests at Kwajalein... 2... 2 ee ee eee we ewe 
Miss-Distance Indicator for ZEUS Tests. . 2... eee ewe ee wwe ews 


SATELLITE TEST PROGRAM .. 2... ee ee eee te ew ee ew were ene 
DISCRIMINATION AND SUPPORTING RESEARCH ON ZEUS PROGRAM..... 
ZEUS R&D TEAM. 2. 6c wee ew tt wt te tw we te es 
ZEUS MULTIFUNCTION ARRAY RADAR — MAR-I.... 2.22 eee ee eee 


NIKE-X R&D SYSTEM ... 2... 2. eee ee te te tw we te ew we ee ewe 


System Objectives. ......+.-..+. or ied Sete GSS el He ee eee es ese 
SPRINT Missile Development... 1... 2.0 +e see ee erect neevens 
Missile Site Radar — MSR. . 2... 1.2 1 ee wee ee ee te et tee wee 
Multifunction Array Radar - MAR-IT. 2... 2. 2c ee eee eer ee we 
Data Processing System... 1... ee ee ee eee ee ee te ete we ts 


Page 


I-32 


CONTENTS (Continued) 


Part I. HISTORY OF ABM DEVELOPMENT (Continued) 


REENTRY MEASUREMENTS PROGRAM. ..... 2.0.2. cee ee eee cceae I-41 
Wth-COUNTRY THREAT 4 :aoc's.a-a.s du Bao Ba ae Gt nS eats Feel 
J-67 STUDIES LEADING TO SENTINEL SYSTEM ........20 e040 J-44 
SAFEGUARD SYSTEM .... 2... 0.2. ce ecw e ern ence reese veces I-45 
ABM R&D SUMMARY. ... 2... ew cee ee ee ee wee we ree rer eae J-48 
Part f. MAJOR SYSTEMS AND SUBSYSTEMS 
Chapter 1. NIKE-ZEUS System 
THE NIKE-ZEUS INSTALLATION .. 2... 2. 2c ee wee ee er were wwe 1-1 
Defense Center... 22. ec ee eww seer wee rr semen w ere ee nvae 1-2 
Battery ees oo Ge ee eg BaF a: ey, Hse a peewee, Maa, BlR Na! dee fete Me GOs 1-3 
ZEUS ACQUISITION RADAR... 2.2.2.2. eee s ee ce renner av ecees 1-4 
Transmitting System. . 2... 1... we eee te eee te weer we er ene 1-5 
Receiving System ........6. bi eater eiaes. ok So torte- bute: WG cas ey euerser © esos LST 
Signal Processing Equipment .........00 00 ec eevee etrervee 1-8 
DISCRIMINATION RADAR .. 1... ee eee ete ee ete tw ee ee ete 1-9 
MP Parie Or iy e202 81k O-PS Bnd Sl Da ees he Wa ea aS 1-11 
ANUGRMA 5 52 Seok, Geka eee eee ee, eae ease 8a leo res Mie! SSS 1-11 
PROC OLV.ORT 6? 5025p eS oy atlas ale wissen se ye Tt8: se ais eh Feason ty doglan Lave) cebdel cbs) Ge, Ser Cen es Seas naie 1-14 
Data Processing Equipment... 2... 2 ee ww eee er we ere eran 1-14 
TARGET TRACK RADAR. 2s tes ee we wee ee we Hee 1-14 
Transmitters. eased 6 wie er we ae Be ae Se, Se 1-14 
Antennas, 5) i6eiée 50 ire a Rw dat Sree DONTE ne: 7 eran ten Salvoue o- ~.. 1-14 
ROGOLVER ia ide See ee Nea Se Se ee a we 1-17 
Data Processing Equipment..... of eicth We bag BUR na entero Beevers 6 wears Se1T 
MISSILE TRACK RADAR........22086 Siibe wie lo 8S Te etiebea: toi GE 8 ae: LTS: 
PYAMSMAUCO 555. 5 8s ta ee Si gal Se Aa hg veh fa wt ee eS Ra ee es GL es 1-18 
vi 


eter 


Veet ed 


ut 


CONTENTS (Continued) 


Chapter 1. NIKE-ZEUS System (Continued) 


PATE CNN A635 5522 ce ate Sek sale is ak Sita ssh ca eta nai aPw pecan Yo cate gas carter, ee aera se 1-18 
Receiver........ ei jeley beh 8d: wen I: cate Sn feh Hee santa Sit ates Ved eey ot eae eis os oe. 1-21 — 
MISSTB soe fas se. ei eas Be ees eee ei Pe aes ere Boe Aree Sia ed 1-21 
DATA PROCESSING EQUIPMENT ........0 000 ee ee cee ear ees 1-25 
Functional Organization. . 2... 2 eee eee ee ee eee tee wee te ws 1-25 
Modular: Structure ooo sae eres a eee la ek hw ie aw POL: 1-26 
Stores .....-.e08- sehen Ose ey eC be oe cien, 169% in ete ve Zoyle CE yaw ss 8 Se ey Se, S82 


NIKE-X CONCEPT ... wc se ever ere e crn vrvre nen even eseses 2-3 
DEFENSE OF STRATEGIC FORCES — TERMINAL/POINT DEFENSE...... 2-3 
BASIC NIKE-X SYSTEM .. 2... cc eee ever eer ew tn ern eenene 2-4 
Threat Description . 1... cece een ees eee e nse eee eter sens 2-4 
System Architecture and Operational Concept .........e0ee0eee024 24 
Functional Capabilities of Major Subsystems ....... eee eee eee 2-7 
Nth COUNTRY DEFENSE STUDIES. ......+6 2c eee eve vercvsves 2-10 
Defense Objectives . 2... 2... cee eee ew ee eee etree rr eens 2-10 
Threat Description ... 2... 22 cee eee eee ee renee nee nc eee 2-10 
Operational Concepts «0 os. %. 6 6 Ba ee caw oe ose 888 a ees we ew cee 2-11 


Modified SPARTAN 2.1... cc eee eee ee eee ee wee eee ee ee «FMP 


DEFENSE OF STRATEGIC FORCES — TERMINAL HARDSITE DEFENSE.... 2-12 


PARALLEL ELEMENT PROCESSING ENSEMBLE .........-. vee ieh Oe eawce 2-13 
Hardware Feasibility .. 1... 2. ee eee err eee reer re ren eee 2-14 
Software Development. .....-. cee cece ceresvcvee Boe ee a2 BE ey ss 2-14 
Application Studies .. 1... 2c eee eer een err eer vce ancrecese 214 
Lessons Learned ..... cece cer ecvresee ita Fa ia SS, ce os 2-15 

REENTRY MEASUREMENTS PROGRAMS A, B, ANDC .......2e2.2- . 2-15 
Test Objectives .... ccc cee sce rece nse ves vsesesesene 2-15 
Target Vehicle Summary ....- 2.2.0.5 cece etree ver ever vccee 2-16 
Missions and Data Reports ..... 2. see eee err creer eenreseos 2-16 


vii 


CONTENTS (Continued) 


Chapter 2. NIKE-X System (Continued) 


MULTIFUNCTION ARRAY RADARS ......2.. 2.2. cece eee ereecreseae 2-16 
The MAR-I Program . 2... wee eee ee we ee wee rt we we we ww ee we OG 
Functional Capabilities .. 1... 2 eee ee ee we we we ew we ete wr ee wee 2-17 
System: Description, 6.0 -eice: o08-e eke ie, Swe es eee, eR a, 8 Gee ow dW ee ee 2-19 
Multifunction Array Radar (MAR-T) ... 2... eee ee ee ee tt et es 2-22 
TACMAR 6. coc 25 jente Sapo ten ce 85 or el se Se See Sole ps let 08-8 2 > ws Sl deis oe St tem ewe ener 2-22 
MAR/TACMAR Subsystems ..... 0.2 e ee eee cree ec cenne 2-22 
Conclusions: 4¢ 0: co: iasiere: Yer oe ai obo ee Bsa ae Samet Bl oe Deel We SUS Tele! ap Ge argal as BES ae 2-24 

GUARDIAN (FORMERLY CAMAR) PROGRAM. ........00000 ce eee 2-25 
Program Objectives... 1... ee ee ee tt we ee eee tet we ws 2-25 
Development Progress .....:2ecceceeveee Soho et ae Os Ore Bes 2-26 
Development Plan... . ewe eee ere cer eres erence reese 2-26 
Demise of the GUARDIAN Program .......20 0c eee ecvrveveves 2-26 


Chapter 3. SENTINEL System 


SYSTEM DESCRIPTION i5-4: 6 4.40 Gold Wa iah wae WR aeew wh's 3-1 
Deployment. . 2... ew wee reer were wees 6: 86 Yee aeenies Meee e. 0! Cores 'e te 3-2 
Area Coverage... 1... esse eevee at eh ental fats gh Brae ora eS Wear BL evens SEZ 
Minuteman Defense Coverage. ........4502+0. piel ene an ow Teas wine 3-3 
Command and Control. . 2... ee ee ee we ee ew eee wee wr wwe 3-3 
System Operation and Response. .....2 cece vere river esese 3-5 
System Readiness Verification .........0.ecccccccees oe ee 3-6 

SYSTEM REQUIREMENTS AND DEVELOPMENT. .......+..-. ano iE Soitels 3-7 
Documentation... 1.2... 2c eee as at lo: ee NEN eS Niat dele) a eatole, fede met, fe 3-7 
System Engineering ............ ig ee gh Been aves gered Sg Gg es . 3-7 
Missile Site Radar. . 2... 1 ee ee wee we ew ee eee ree reece ee 3-7 
Perimeter Acquisition Radar... 1... eee ee eee wee eee we eo ee 38 
SPRINT Missile Subsystem .... 2... 2c eee eee e ere eer cee ne 3-8 
SPARTAN Missile Subsystem... 1... eee eee ee er eee renee 3-8 
Data Processing (i353 4.6 6-8 6.6 o Gees 8 ee NOR we Bere ee 38-9 
SOLC WALCO 5.5/6.5 ar So: Ge ca eke Seed en E elcal as Naw Sw Sel anes 6 FOO LATS LOS 3-9 


TOStNG ys eb eee hw hire ee Seay ee Wee tad Be oO ell bd oh alee eB H1O 


SUMMARY AND CONCLUSIONS ........2e+6. O, 8o ah Mee ost TOS: seen eites la 3-10 


viii 





Al 
oy 

4 
vel 
oa) 





CONTENTS (Continued) 


Chapter 4, SAFEGUARD System 


MAJOR SAFEGUARD ELEMENTS ........ cc seer cece reeves rneccee 4-3 
Perimeter Acquisition Radar .. 0... 0c. cee eee et tne Bley bed 
Missile Site: Radar «0c: ycice: oaceeer be cia Sane dees a acetate ea cas P Ale Ser ela Bre 4-3 
SPRINT Subsystem ........ cc eee rere vnes eagle Te eh cd BRS bua hehe ovale e 4-4 
SPARTAN Subsystem. . 1... cee cee ee et ee ee ee ee ee eee eee 4-5 
Data Processing System... .... cc eee cee ee te te eee eee ee eee eres 4-6 

SOFTWARE DEVELOPMENT ........-.-506. be Sb cersel aN e at Vso a etten 83 cece eer ese 4-8 
Development Cycle 1... . ccc ce ee ee eee ree eee reenter ne eeene 4-8 
Meck Test Facility... 0. cece ee ec cere reenter e etre esees 4-9 
TSCS and System Exerciser ...... ccc eee wee eee ewer ewe eee ee enee 4-9 
Requirements sci sited SS al ekg, Gk e Gelb aia aca Ne matinee ee dee eb al at a ate tere 6 4-11 
Software: Design 66654. e lee Si ee oie he a ere eee wow Be: OS Here gS ar eee 4-12 
Coding and Unit Testing .. 0... cee wee ee tee eet tees 4-12 
Process and Functional Integration ......... 0c. vec eee sree nececes 4-14 
Site Integration and System Testing ....... 0... eee eee were eee eveves 4-15 

SAFEGUARD OPERATION AND: MAINTENANCE .......2¢ 20 ccececccroes 4-16 
Operational Overview. 2... cc ee ee ee ee et eer eee ees 4-16 
Tactical Command and Control... .. 2... cece eee ee ee ener er esses 4-17 
System Maintenance ...... 2. .e cece cern ce ceoes i EP Sete eeee 4°17 
TSCS Operational Support 2... .. ccc ce ee te te wee ee eee eee tenes 4-19 

LESSONS LEARNED .,.. 1... cc ccc eee ee ee eee ne eet e teens 4-19 
GOMOT AD eg sss vas dere swt lb. cesar cet eecks Bla Roe bs Ges Bi -w eLearn: Vol Be 6B Navies BLS HD we BCS 4-19 
Support ComputerS 2... ... ec cee ce eee terre reer reese ew eeeee 4-19 
Support Software ......... sl eiate pede, So'eoies adaCR aie 0 ewan es ove whe Wha So hvelse oe. 4-20 
System Exerciser 6s) obverse doo 6 We eevee a es ae he Bee a a eee ew 68 4-20 
Patching, Debugging Tools, and Testing ...... ccc cee csccersvecses 4-21 
Modularity, Redundancy, and Multiprocessing .........c0000eseeeeese 4-21 
Error Comty ol) i555 oi eats aceite, ites ena Sy wee ab Sw ae eee ON ate Pete oh 4-21 
Maintenance Approach ..........ecee008 I Gh S oa aE wa, @ Sree tee ere ee aoe 
Development of Computer Languages ......... 0. cece cece eer eeceee 4-22. 
System Programming in PL/1 ... 0.0... cece eee ee ee et eet eee 4-23 
Professional Design Review... 1... 0. ce eee eee ee eee e ee eee 4-23 
Software Change Control ....... cee cee eww eee te te ee eee awe ee 4-24 
Syatemt Constants 5 4<..¢ iy ose Saea otts nae eee Gd Meas WE RSS 4-24 


ix 


CONTENTS (Continued) 


Chapter 5. SAFEGUARD System Evaluation 


APPROACH TO SYSTEM EVALUATION. .......-22. ccc ceevcvcee 


MAJOR SIMULATIONS ......0 00. eee ee eee ee wee ee ee eee! 


System. Simulatlon: s+ oo. S) seco: 5 ev es se 8 iol Wt) ae G06, tee 0 8 ere BSS, 
MSR ‘Simulation’ 5s). o: ese eee a oar fa ep See erg eG era sala) os eae 
PAR/SPARTAN SAFSIM. 2. 2. . we eee ee et tt et te es 
PAR TOSEDEGG ss: 25: a2 16.0! teers Gaias! fern G8 Torte LD ale) erg en ia Ae Sad wl eS Ordo Wee 
SPRINT Engagement Simulation. ........... Oe a a ae er ee ee 
SPRINT Intercept Simulation ...... 0... eee eee eee eee t ene 
SPARTAN Intercept Simulation... 1... 2... e ewer ere cence ee 


ANALYSIS AND KEY RESULTS. .....-...-2++00- ee eee ween 


MSR/SPRINT Performance and Characterization. ........-2+ee80068 
PAR/SPARTAN Performance and Characterization .......-2.-0ce2808 


SYSTEM TESTING AT MECK ISLAND... 2... 2 2 ee eee eee eee cee 


Ob] OCEIVES 2 65:0) co i seas ase co GA ao we Se es, horas Ste May Se, Mtoe ay Tae secon ehte 
Test Requirements ......0 cece severe re ae ee ee ee 
Meck System versus Tactical System. .. 1... 2 ee eee eer eee e ae 
Test Targets versus Design Threat. . 2... 2. eee ee eer ere cee ne 
SAFEGUARD Hardware Facilities and Functional Capabilities......... 
Data Recording and Reduction Facilities at Meck ........+.eeeee-. 
Range Support Facilities. .. 1... we we ew we ew we we eww ee reno 
Program Coordination with Other Agencies. ..... 2... ee eee eevee 
Program Planning and Mission Design .... 2... 2-0 e eee eee reece 
Test Requirements Memorandum... . 2.2... eee eevee cence eoee 


Process Verification, Function Integration, and Mission Certification 
at Whippany and Meck... 2. pe ee ew ee ew ew er wwe err we eens 


Premission Radar and Missile Checkout .......20-..0 0222 ce eeee 
Mission Summary Information. .. 2... 6 ee ee wee wee eww error eoe 
Targets of Opportunity, 6... 1 we ew ee wee eee tee tt we 


INTEGRATION AND DEMONSTRATION TESTING AT TSCS AND SITE. ..... 


System Integration Testing ........0.0 cc eee severe rveveae ee 
AcCeptance Testing: sé 6.25. iste: Se che w io i6k Aone sah Se get ee Tay bs a foe eva ee Bae we 
System Readiness Verification Tests. ........2e0.8 Ca eer a ee at eae 
Evaluation and Simulation Verification... ....-. 20sec cere ohne 


MAJOR CHALLENGES AND INNOVATIONS .....-..-50.000e28ee0 208% 


Cost Effectiveness of System Evaluation... ..... 22 ee weer tees 


Keeble 


Sats, cashes} 


fal 


ees 


CONTENTS (Continued) 


Chapter 5. SAFEGUARD System Evaluation (Continued) 


Multisimulation Approach to System Evaluation .........26.2++2e08 5-41 
Iterative Approach to Analysis of Complex System Problems ......... 5-41 
System Exerciser Evaluation ...... 2.2. eee ee eevee ere evens 5-42 
Requirement for Intermediate Level System Design Documentation. ..... 5-42 
Evolution of Meck System Test Program ........-+ see ee ee eee 5-42 


Chapter 6. Nuclear Vulnerability and Hardening 


ACHIEVING HARDNESS ...........000000. Ba celeste ca 6-1 

MAJOR CHALLENGES AND INNOVATIONS ......-.2c cee cccrveves 6-4 
Shock and Vibration in Ground Equipment. ........ 2. ee ee eevee 6-4 
Blast and Thermal Effects on Exposed Equipment .........620e-cee 6-5 
EMP Hardness Assessment for Ground Equipment....... abe ak ene . 6-7 
Conduit Problem. ... 0... 2 eee eee ee eee eee eee ee ee ee e)©6 6 GH11 
Dust and Crater Ejecta Environments. ..... oS Me ea es eee eg Se 8=T2 
Debris Environment... 0... ce eee ee ee ww ee wee te ee we we ~=6 612 
Missile Guidance Set Power Supply Failures. ......-.-ee00 ee ees . 6-18 


Radiation Effects in Tantalum Capacitors .....-. eee eee eee eee e = 615 
Internal EMP in Missiles... 1... ee ee ee eee eee ee we ee ee ee ew) GH 


SPRINT Autopilot Transients... 0.1 ee we eee tw ee tt ewe ww es 6-16 
Radiation Effects on SPARTAN Missile Structure ........-2.500eece8 6-17 
SPRINT Blast Evaluation .... 2.2.2.2 ee sec eeevvceee one eee e = 6 8-18 
ASSESSMENT RESULTS ..........0 2c ee eve eeeevevrenveves 6-19 


SYSTEM CAPABILITY ......-.-2.006. soe ee mee reer rer ens 7-4 
ANTENNA DESIGN . 0... 6 ee eee cee te tee te ee te ww we twee 7-6 
RECEIVER DESIGN. . 2... 2 eee eee te eee ee we ww ew ee eww es 7-8 
TRANSMITTER DESIGN .. 0... ee ee ee eee ee ww ete eee er rene 7-10- 
RADAR CONTROL DESIGN. . 1... 1. 2 eee ee ee te ee eee ee . wee T2158 


xi 


CONTENTS (Continued) 


Chapter 7. Missile Site Radar (Continued) 
COM PARISON OF PERFORMANCE OBJECTIVES AND RESULTS ........ 7-17 


MAJOR CHALLENGES AND INNOVATIONS .....-..2-22 00> J 2etehce Masi wee “20 7-18 


Chapter 8. Perimeter Acquisition Radar 
SUBSYSTEM DESCRIPTION .. 1... 2. ce eee ewe re renee eee nes 8-7 
COMPARISON OF PERFORMANCE OBJECTIVES AND RESULTS ........ 8-10 


MAJOR CHALLENGES AND INNOVATIONS ........2-+-6-. 


VHE versus: URE! <6) sccciseris aoe dice eek Be So Biel Serer ies en BE ena Bas eS 8-10 
Transmitter oc: ae cee 6 oie ai a 6 TOS ee a es aw So ecb a oe 8-11 
Antenna Element... . 2.6.22: cece veer everevreseseseras . 8-12 
Phase Shifter. ... 0. ees ee eee ee tes ys WBE Ei van Bere oes bn eh whe wes ve 8-12 


Receiver RF Amplifier... 1... 22 ee ewe ee er ee eee ee eee ew es) BH14 


Maintenance and Redundancy ....... 2 cece eee ve eer revvue 8-14 
Chapter 9. SPRINT Missile Subsystem 
MAJOR CHALLENGES AND INNOVATIONS ......200 520200 cece eevee 9-3 
DESCRIPTION ...... So 1So Bites BivreSrieetahene. “Set Se Ner's. conte: elves eer Se Pe vee Lge) 9-3 
MISTS 655.150) ie ee bee Seed se: ON WE a I a a ae Ss Sa es SS , 9-3 
Launch Station. ........eee0-6 Oe WA ee a eh We op es te, WS, Tar el eae ~~. 9-7 
Remote: Launch. 62:6. gece see cea Bote ee: eee ee i ee wee eS 9-9 
Ground Support Equipment... 1... 2. eee ee eee eee ew te tee eee 9-9 
SUBSYSTEM DEVELOPMENT PROGRAM ..... 20s cs ee ceeectave 9-11 
Propulsion. .... ah Ge acne espe tte leet vot cae Weis ace ‘ec "wie! Gol igs Ht coe), fo hs Gon os Wee: “ORL 
First-Stage Control System... 2... ewe eee eee ree we ter vee 9-15 
Second-Stage Control System .. 6... eee eee eee ee ee ne +. 9-16 
Heat Shield. ..... bs Fash coe? OCR Ee SIE Re ALG We, Bose a eRe 9-17 
Autopilot. ...... Bros oe! fisly Hirai res tol <a) set sot tn: Todeb! cae! Diets NE a see al ve,)rar. ter “oye 8 9-18 
Launch Eject iss e's eines See eS varie, ire cas Loe le oe We ae yal ee ee En ehLe eee 9-19 
Staging. ....... as aithly Sen Tae Ww nen te) Lie Gi Bt Cue! Gel velyer eral ah Golies Sew Bhai we? Wet 9-20 
FLIGHT TEST PROGRAM ..... 2... eecevsevvecerves oe ie 9-21 


xii 


Peg 


yh’ ent 


CONTENTS (Continued) 


Chapter 10. SPARTAN Missile Subsystem 


MAJOR CHALLENGES AND INNOVATIONS .... 2.2 eee eee eer eve 10-3 

DESCRIPTION’ 2in.2.005 20 os lh aie ee Reel BS oe ane ge 10s 
SPARTAN Subsystem Operation. .......6 cc cee cere err erro ere 10-3 
MISSILE oe otek Bienes Sree ee cee, oo 8 et else 8, Ges Fes Wer ae wea See ee menial rae te 10-4 
Launch: Stations. oe. @ eee betes: See ACERS: ce es eee ee lw Boas 10-5 
Launch Preparation Equipment Set ...... 50. . ee eee eee oe evens 10-7 
Ground Support Equipment. ... 2... 2.2... ee eee cece vate de few te ses fe te 10-9 

SUBSYSTEM DEVELOPMENT PROGRAM.......2eecevevevveses 10-10 
Propulsion sss: (soi ese eee: te sa as We ede: cla cas ne Se Aw nee ES ep we 10-10 


Missile- Borne Guidance Equipment. ....-.. e+e eee e ee eee eee 10-12 
Launch Preparation Equipment and Fault Isolation Test Set. ......... 10-13 


Hydraulic System ..... 2c cece rccrc ee nesresesesseves 10-14 
Launch Cell Protective Cover... 1... eee ewer eer enn e neers 10-15 
FLIGHT TEST PROGRAM ..... 2-2. eee eee eee eer earner rsces 10-16 
Kwajalein Development Tests...... Ries deh tel, farei, ves f0> Bese es ser Ake Se? ale 2 5s 7S 10-16 
Meck System: Tests) iris; ce Ged Set 556 Bele eerie eo se ee a eS es Jee Bes 10-17 
Summary........ er tetpenget: Siete? oles: (edn et Br ietgel ie Meat Ge ce) eer eters, 10-17 


Chapter 11. Data Processing System 


SUBSYSTEM DESCRIPTION ......... Ce Ua et ea bo ate vleitel Wate. Sere 11-2 
Central Logic and Control (CLC)... 1... ee ee eee wee ewe te ee we) = 11-2 
Recording Subsystem (RSS) ........0-e2e0008 oat oe Goce te le vetel se ys. - 21S6 
Interface Subsystems .........2-. ened ke Sou ee an a eet ® werent © L1S6 
Maintenance and Diagnostic Subsystem (M&DSS)..... iia care tat a At Te aah aT 11-8 
System Readiness Verification (SRV) Subsystem. .........c.00e0e08% 11-8 
Command and Control Display Subsystem (CCDS) .........-..028e008 11-9 © 


COMPARISON OF PERFORMANCE OBJECTIVES AND RESULTS ........ 11-12 


MAJOR CHALLENGES AND INNOVATIONS .........-. ease hG ote te. evens 11-14 
A Multiprocessor, Partitionable System with (n+1) Redundancy. ....... 11=14 
A Versatile and Workable M&D Approach. ......+.-eese006 eee - TSI 
A Processor Unit with a Basic Operate Time of 200 nsec ..... 2.52 eee 11-17 


A Coupled Film Memory with a 68-bit Word Length and 200-nsec 
Cycle Time: 6.65.6! e. Sier sce staiss We ices 8 he, OES aU elie ee gia ele, sarees SPIRIT 


xiii 


CONTENTS (Continued) 


Chapter 11. Data Processing System (Continued) 


A System Readiness Verification Subsystem for Realistic Simulation 
without Relying on Processor Self-Checking ..... 2... ee se eee eres 11-17 


A Quick-Reaction, Remote-Controlled Nuclear Safety System. ....... . 11-17 


Chapter 12. Ballistic Missile Defense Center 


ROLES soiyee os 550 os eit SR edad esto NN ee Sg ice cee ale wR a, RY hn BS Pera wire 12-1 
DEVELOPMENT SCHEDULE. ...... eee ever verve vreervesves 12-1 
DESCRIPTION oso: ve-8 heise Oe we accel os eee ALE Ok Whiter Swe 12-3 

FArdware > 66s 68: ee wie SS Rg en a 8 BS A) eR SO we ie Re SO 12-3 


SOGEWATO: 63) 20:6 wien bi 5s GB eice ents eiceice, Slew eo eee eel a St ew Sea ws) 1256 


Part 11. MANAGEMENT AND OVERALL APPROACH 


OVERVIEW 6. opie r6 3 Setas cea eee eee on Soe ot es et ee ee a ee ee a 4 I-1 
Feasibility. ......... Sihlen air te a The Us Seip: Ze:iyies a> or cey ek. giv. aL eal iel 1S lat I-1 
Overall Approach: 6 ie: <0 icv. oobi ce Steet ee ee SS eH fe) So ee 1 eS, TI-2 


Organization. 2... ee ee eee we we we we we ne 


SPECIFIC SUGGESTIONS. .. 1... eee eee rr een ere cr eves . 1-5 
Requirements’ <é.6. 666 hee RRR ADA Hee ee we Ss es ae Sere, oe DI-5 
Hardware Design Implementation. .. 1... 2c eee eee cern ee rneoe HI-8 
Organization of Work .......620e02006 Feathers wana tie a Raa Se ee tees m-9 
Management 6:6 ise ee ee ie ee a ee 8 eta he ee Se ee I-10 
Miscellaneous .. 1... 2c cee err er er etree reese ee nee evans II-15 


xiv 


toed 


CONTENTS (Continued) 


Part IV. REFERENCE DOCUMENTS 


References for Chapter 1 


NIKE-ZEUS System. 2... 1 ee ee eee ee ee ee ee bse ible Goce Nae ta Oe 8 Iv-3 
References for Chapter 2 ° 

NIKE-X System... 2... eee eee eee cees eye eee ey a lots ee oe Iv-7 
References for Chapter 3 . 

SENTINEL System .. 1... 2. ee eee ee eee eee rr ewe eer e rene Iv- 13 
References for Chapter 4 

SAFEGUARD System ..... 2-0-2 ee eer e rere eve oh fairies Sere nah “Oh eta ha Iv-17 
References for Chapter 5 

SAFEGUARD System Evaluation... 2... eee eee weer eer ena IV- 27 


References for Chapter 6 
Nuclear Vulnerability and Hardening. ... 2... 2 2 eee eee eer eevee ..» Iv-35 


References for Chapter 7 
Missile Site Radar . 1... 2c ee eee ee we wr ee we rw eer ere rere cen IV- 37 


References for Chapter 8 
Perimeter Acquisition Radar... 1... 2.2 ee ee eee eer eee oe oe ees IV-43 


References for Chapter 9 
SPRINT Missile Subsystem... 0... 0. ee ee eee ee we we we ww wee eee © )©=6IV- 45 


References for Chapter 10 
SPARTAN Missile Subsystem. ... 2... 00 cee cece ececreceeceee I-51 


References for Chapter 11 
Data Processing System .. 1... 2. ee eer er ere eee ree eee eee We 57 


Part V. GLOSSARY. .......0e6eee4868 V-1 


Part VI. CLASSIFIED SUPPLEMENT 
(Separately Bound) 


XV 


Figure No. 


I-1 
I-2 
1-3 
I-4 
I-5 
I-6 
I-7 
I-8 
1-9 
I-10 
I-11 
I-12 
I-13 
I-14 
I-15 
I-16 
I-17 
I-18 
I-19 
1-20 
I-21 
1-22 
I-23 
1-24 
I-25 
1-26 


1-27 
I-28 


I-29 


I-30 


1-31 


I-32 
I-33 


. 


ILLUSTRATIONS 


Spectrum of Target Threats 

Defensive Missile with Interchangeable Noses 
ICBM Trajectory 

Ballistic Target Characteristics 
Comparative Sizes of Early ABM Missiles 
Deployment for ICBM Defense 

ABM Battery 

AICBM Acquisition Radar 

Luneberg Lens Antenna 

NIKE-B System 

Mechanization of Parallel Approach for ICBM Targets 
Battery Capability vs. Target Angle 
Variation from Nominal Intercept 

Radar Range Requirements 

ICBM Coverage in New York Area 
Long-Range Track Radar 

NIKE 1 Plan of Integration 

Proposed Forward Acquisition Radar 
Proposed Local Acquisition Radar 
Weapon Battery Installation 

The Defensive Missile 

Fly's Eye Antenna 

Fly's Eye Antenna Feedhorn Structure 
Fly's Eye Antenna Coverage 
Discrimination Radar 


NIKE-ZEUS System Installation at Kwajalein, Looking 
Toward Lagoon 


NIKE-ZEUS System Installation at Kwajalein, Aerial View 


A 75-second time exposure of the K-2 Atlas D intercept at 
Kwajalein on July 19, 1962. Picture was taken from Carlson 
Island (5 miles northwest of Kwajalein). 


View of the August 15, 1963, K-26 Titan I intercept test at 


Kwajalein. The ZEUS thrust-vector motor trail and spotting 


detonation (arrow) mark the successful intercept. 


A 120-second time exposure of the March 30, 1963, K-17 
intercept test at Kwajalein. This was the first intercept test 
to be conducted against a Titan I-boosted target vehicle. 


Two 120-second time exposures of intercept test K-21 con- 
ducted April 13, 1963. 


Aerial View of MAR-I at White Sands Missile Range 
Proposed Tactical MSR 


xvi 


creased 


we 


ad 


Page 


I-2 
1-3 
I-4 
1-4 
1-5 
I-7 
I-7 
1-8 
1-8 as 
1-9 

1-9 a 
1-10 “4 
I-10 

I-11 

I-11 
I-11 
I-12 
I-13 
I-13 
I-14 
I-15 2 
I-17 , 
1-17 ; 
I-17 
1-19 


~y 


1-25 2 
1-25 ni 


1-27 
1-28 


I-29 


I-30 
I-35 
I-38 


Figure No. 


I-34 
I-35 


I-36 
I-37 


1-1 
1-2 
1-3 
1-4 
1-5 
1-6 
1-7 
1-8 
1-9 
1-10 
1-11 
1-12 
1-13 
1-14 
1-15 


1-16 
1-17 
1-18 
1-19 
1-20 
1-21 


1-22 
1-23 
1-24 
1-25 
1-26 
1-27 
1-28 
1-29 


2-1 
2-2 
2-3 
2-4 


ILLUSTRATIONS (Continued) 


MAR-II Planned for Kwajalein 


TTR 4 Antenna, showing 40-foot reflector with subreflector 
being readied for use in RMP B 


SAFEGUARD Deployment Plan, March 1969 : 
Summary of Major ABM Developments, 1955 through 1975 


The NIKE-ZEUS Installation, Artist's Conception 

The NIKE-ZEUS Installation, Symbolic Block Diagram 
Minimum and Maximum Battery Sizes 

R&D Model of ZEUS Acquisition Radar (Kwajalein) 
ZAR Transmitting System 

ZAR Receiving System 

Multiple Receiving Beams Formed by Luneberg Lens 
ZAR Receiving Antenna, Cutaway View 

ZAR Signal Processing Equipment, Functional Block Diagram 
R&D Model of Discrimination Radar (Kwajalein) 
Discrimination Radar 

Focusing/Defocusing System of DR Antenna 

R&D Model of Target Track Radar Antenna (Whippany) 
TTR Klystron Amplifier Section 


Comparison of Range Obtained with Maser Receiver and 
Other Receivers 


Battery Control Building with Missile Track Radar Antennas 
R&D Model of MTR Antenna (Whippany) 

NIKE-ZEUS Missile, Cutaway View 

NIKE-ZEUS Missile in Launch Pit 

ZEUS Missile-Borne Guidance Unit 


Major Computing Equipments of NIKE-ZEUS, Simplified 
Block Diagram 


Signal Flow at Battery, Simplified Block Diagram 
Target Intercept Computer 

NIKE-ZEUS High-Speed Digital Computer 

D-Unit for NIKE-ZEUS Computer 

C-Plane for NIKE- ZEUS Computer 

Logic A-Module for NIKE-~ ZEUS Computer 
Twistor Wire 

Twistor Store | 


Map of the NIKE-X Era 
City Defense 

SPRINT Missile Firing 
ZEUS Missile Firing 


xvii 


Page 
I-39 


I-42 
I-46 
I-49 


1-3 
1-4 
1-5 
1-7 
1-7 
1-8 
1-8 
1-9 
1-10 
1-11 
1-13 
1-15 
1-17 


1-18 
1-20 
1-20 
1-21 
1-22 
1-24 


1-25 
1-27 
1-28 
1-30 
1-30 
1-31 
1-31 
1-32 
1-33 


2-2 
2-5 
2-8 
2-9 


Figure No. 
2-5 
2-6 
2-7 
2-8 


3-1 
3-2 
3-3 
3-4 


4-1 
4-2 
4-3 
4-4 
4-5 
4-6 
4-7 
4-8 


5-1 


5-3 
5-4 
5-5 
5-6 
5-7 
5-8 
5-9 
5-10 
5-11 
5-12 
5-13 


6-1 
6-2 
6-3 


6-5 


ILLUSTRATIONS (Continued) 


Close-up View of MAR-I at White Sands Missile Range 
MAR Functional Capabilities 
MAR-I Functional Block Diagram 


TACMAR Block Diagram 


Locations of Sites for SENTINEL Deployment 
Ground Impact Area Coverage 

SENTINEL Command and Control Structure 
Area Control Center Number 2 


SAFEGUARD ABM System 

PAR Building 

MSR Site 

SPRINT Cell with MSR in Background 

Data Processing System Equipment 

Tactical Software Control Site Functions 
Functional Configuration for System Exercise 
Software Preparation and Testing 


Effectiveness Evaluation Procedure 

Meck Island Installation 

Meck Island Facilities 

Mleginni Island Location and Site Plan 
Range Instrumentation Sites in Kwajalein Atoll 
Test Planning Cycle 

Target Procurement Cycle 

Software Development Cycle 

Meck Mission Summary 

Summary of SPARTAN Intercept Locations 
Summary of SPRINT Intercept Locations 
Targets of Opportunity Mission Summary 
SAFEGUARD System Test Program 


Nuclear Weapon Effects on System Facilities 
ABM Site Protection Volume 

PAR Amplifier Modulator Cabinet 

Modes of EMP Interaction with Shielded Building 


Frame Building Subjected to 15 psi Overpressure, 
Operation PRAIRIE FLAT 


xviii 


Page 
2-17 
2-18 
2-20 
_2-23 


3-2 
3-3 
3-4 
3-5 


4-2 
4-3 
4-4 
4-5 


4-10 
4-11 
4-15 


5-2 
5-18 
5-19 
5-20 
5-24 
5-25 
5-26 
5-29 
5-33 
5-34 
5-34 
5-36 
- §-39 


6-3 
~ 6-6 
6-8 


6-14 


20d 


Neen 


aed 








Figure No. 


6-7 


6-8 


1-2 


8-7 
8-8 
8-9 
8-10 
8-11 
8-12 


9-1 
9-2 
9-3 
9-4 


ILLUSTRATIONS (Continued) 


SPRINT Missile Guidance Set Being Readied for 
Gamma Radiation Tests at Aurora Facility 


Internal EMP Testing of SPARTAN Missile at 
McDonnell-Douglas Astronautics Company 


SPRINT Missile Undergoing Shock Tests at Sandia 
Laboratories 


Prototype MSR — Meck Island 

Tactical MSR — North Dakota 

Prototype MSR Schedule 

MSR TSCS Schedule 

Tactical MSR Installation and Test Schedule 
MSR Functional Block Diagram 

MSR Array Element Installation 

MSR RF Chambers 

IF Receiver 

MSR Low Level Transmitter and Consoles 
Klystron Room 

Single-Pole, Double-Throw High-Power RF ''Face"' Switch 
Digital Control Group Logic Racks 

Drive Amplifier Racks 


PAR Site — North Dakota 

PAR Transmitter 

PAR Design History 

PAR-1 Installation and Test Schedule 
PAR Software History 


PAR Face, Bottom-to-Top View of Phased-Array Antenna 
Elements 


PAR Building, Cutaway View 

PAR, Block Diagram 

PAR, Showing Antenna Measuring Radar on Top of Structure 
PAR Traveling Wave Tubes 

PAR Antenna Element 

PAR Phase Shifter 


SPRINT R&D Organization Structure 

SPRINT Missile and Launch Station . 
SPRINT Missile, Cutaway View 

SPRINT Missile Guidance Set, Block Diagram 


xix 


Page 
6-15 
6-17 


6-18 


7-1 
7-2 
7-2 
7-3 
7-3 
7-5 
7-7 
7-8 
7-9 
7-10 
7-12 
7-14 
7-15 
7-16 


8-2 
8-3 
8-4 


8-6 


8-7 
8-8 
8-9 
8-11 
8-12 
8-13 
8-13 


9-2 
9-3 
9-4 
9-6 


Figure No. 


9-5 
9-6 
9-7 
9-8 


10-1 
10-2 
10-3 
10-4 
10-5 
10-6 
10-7 
10-8 
10-9 


11-1 
11-2 
11-3 
11-4 
11-5 
11-6 
11-7 


11-8 
11-9 


11-10 
11-11 
11-12 
11-13 


12-1 
12-2 


12-3 


ILLUSTRATIONS (Continued) 


SPRINT Launch Station 
Remote Launch Equipment 
Universal Transporter Loader 
SPRINT Missile in Flight 


SPARTAN R&D Organizational Structure 


- The SPARTAN Missile 


SPARTAN Hydraulic Pumping Unit Assembly 
SPARTAN Launch Station 

Launch Cell Protective Covers 

Launch Preparation Equipment Set (Tactical) 
Third-Stage Test Set 

Maintenance Van Deployment Sequence 
SPARTAN Missile in Flight 


Data Processing System 

Central Logic and Control 

SAFEGUARD Digital Racks 

Construction Details of SAFEGUARD Digital Rack 


’ Recording Subsystem 


M&D Subsystem 


Command and Control Display Subsystem — Console, Wall 
Display, and Teletypewriter Interface 


Typical CRT Console with Control Indicator Unit 


Command and Control Display Subsystem — Launch Enable 
Interface 


N Processors Executing from One Program Store 
N Processors Executing from N Program Stores 
Unequal PS Loading, LOGICAL Mix 

Unequal PS Loading, MATH Mix 


Overview of Command Hierarchy 


BMDC Operations Room with the System Capability 
Officer (left), Tactical Director (foreground), Assistant 
Tactical Director (right rear), and System Status Display 
Unit (rear) 


Nuclear Employment Authority Interface 


Nett 


Page 
9-7 
9-10 
9-12 

-- 9-22 


10-2 
10-4 
10-6 
10-6 
10-7 
10-8 
10-9 
10-11 
10-16 


11-2 
11-3 
11-4 
11-4 
11-7 
11-8 


11-10 
11-11 


11-11 
11-13 
11-13 

11-14 y 
11-14 4 


_ 12-2 


12-4 
12-6 


Table No. 


I-1 
I-2 
I-3 
I-4 


1-1 
1-2 
1-3 
1-4 
1-5 
1-6 


4-2 


5-1 


5-3 
5-4 
5-5 
5-6 


5-8 


TABLES 


AICBM Radar Characteristics 
Summary of Early ZEUS Firings 
Summary of Live Target Systems Tests 
Major NIKE-ZEUS Subcontractors 


ZEUS Acquisition Radar Characteristics 
Discrimination Radar Characteristics 
Target Track Radar Characteristics 
Missile Track Radar Characteristics 
NIKE-ZEUS Missile Characteristics 
Target Intercept Computer Characteristics 


CLC Configurations 
Size of Major Software Components 


Major Elements of the SAFEGUARD System Simulation 
(TACSAF) : 


Meck Capability Additions 

Examples of Significant TRMs 
Concept Verification 

Summary of Mission Results 

Radar Evaluation with Waking Targets 
Summary of System Test Incentives 


Resource Comparison Between Present and 1970 Version 
of Meck System Test Program 


Page 
I-6 
I-23 
I-26 
I-34 


1-6 

1-12 
1-16 
1-19 
1-23 
1-29 


5-4 

5-22 
5-28 
5-31 
5-32 
5-32 
5-37 


5-42 


Part I. 


HISTORY OF ABM DEVELOPMENT 
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In March 1955, a small Bell Laboratories 
military system development group working with 
a team from Douglas Aircraft Company (now 
McDonnell-Douglas), had just completed a study 
of a single-stage, solid-propellant missile for 
possible air defense. When Army Ordnance 
asked Bell Laboratories to start an 18-month 
study of a new forward-looking, anti-aircraft 
defense system for the Zone of the Interior to 
defend against future target threats in the 1960- 
1970 time period, a system team already was 
available. 


The initial thought was to place primary em- 
phasis on the super air-breathing-type target 
while also keeping in mind ballistic targets and 
the desire to defend against the extremely diffi- 
cult Intercontinental Ballistic Missile (ICBM) 
with a reasonable extension of current radar and 
missile technology. In other words, the system 
originally to be designated as NIKE II was not to 
be considered as a solution to the ICBM defense 
problem, but rather as a step toward its ultimate 
solution. However, discussions with the Army 
in June 1955 brought to light the increasing con- 
cern over the possibility of an ICBM threat, and 
Bell Laboratories was asked to place primary 
emphasis in this area. Consequently, the 
NIKE II Study would focus on ICBM defense, but 
still include the full spectrum of future target 
threats. 


Part I. 
HISTORY OF ABM DEVELOPMENT 


NIKE tf STUDY 


The relatively small study team available to 
carry out the NIKE II work was actually a well- 
coordinated task group of Bell Laboratories and 
Douglas Aircraft Company people who met at 
regular intervals to review completed tasks and 
outline future objectives. Messrs. C. A. Warren 
and J. W. Schaefer coordinated the overall sys- 
tems work supported by Bell Laboratories' 
Mathematical Research Department, whose ef- 
forts were coordinated by Messrs. D. P. Ling 
and R. C. Prim. At the Douglas Aircraft Com- 
pany, Mr. J. L. Bromberg was responsible for 
the project coordination, supported by Messrs. 
R. L. Johnson, M. Hunter, N. Weiler, and 
J. Tschirgi. 


Initially, the objective was to explore the 
possibility of a common anti-aircraft defense 
system to cover all future high-altitude threats 
without substantially compromising the overall 
defense. It was felt that any anti-aircraft de- 
fense designed for the extreme ICBM targets 
would overlap on a system capable of handling 
the future air-breathing, high-performance tar- 
gets. Consequently, by adding certain special- 
ized elements of one to the other, there was the 
attractive possibility of having an anti-aircraft 
system capable of attacking any future air 
target. 


The spectrum of possible future target threats 
(1960-1970 time period) considered for the Army 
study is shown in Figure I-1. It covered a wide 
area of performance capability from the maxi- 
mum speed of the air-breathing ramjet out to 
ICBM speed of 24,000 ft/sec, and at altitudes far 
beyond 100,.000 feet. For the ballistic targets, 
the short-range, 150-mile, 5000-ft/sec rocket 
of the V2-type set the lower boundary. 


The Army authorized funding of $1.65 million 
on Army Ordnance Contract DA-30-069-ORD-1082 
for the 18-month study effort. This funding was 
to cover not only the system study effort, but 
also exploratory hardware development in those 
areas of radar and missile technology that could 
be defined as critical to successful development 
of a NIKE II System. A year later, an additional 
$1.8 million was added for expediting exploratory 
hardware work. 
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ABM Defense Requirements 


The first full status report on the NIKE II Sys- 
tem Study was presented to Army Ordnance at 
Redstone Arsenal December 2, 1955, about seven 
months after beginning the study. It is interest- 
ing to note here how many solutions proposed in 
this preliminary report, after only one third of 
the study was completed, remain basic even to- 
day to any ICBM defense. Some highlights pre- 
sented at this status review follow. 


To handle the full range of threat, a common 
data-gathering system was proposed using a de- 
fensive missile with interchangeable noses as 
shown in Figure I-2. One nose, for use in long- 
range intercepts of the future air-breathing tar- 
gets, would contain an active seeker. The sec- 
ond nose would have no seeker, but would contain 
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Figure I-1, Spectrum of Target Threats 
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Figure 1-2. Defensive Missile with Interchangeable Noses 


a jet-control mechanism to provide maneuvera- 
bility at altitudes above 120, 000 feet. This nose 
would be used when engaging ballistic targets. 


By comparison to World War II air defense 
objectives, where a 10- to 15-percent attrition 
rate was acceptable, the nuclear-warhead threat 
required defense levels of 95- to 100-percent 
attrition against a tough-to-kill reentry target. 
Studies showed that using a 50-kiloton nuclear 


warhead in the defensive missile required rela- | 


tively small miss distances to kill the enemy 
warhead. The use of a high-yield warhead did 
not relax the need for a guidance system of high 
accuracy. 


One of the first questions in the initial study 
concerned the point in the offensive missile's 
trajectory where intercept should take place. 


1-3 


Consideration was given to making the intercept 
near the middle of the trajectory. However, not 
only would this necessitate a defensive missile 
as formidable as the offensive weapon, but it 
would require gathering information on the offen- 
sive missile almost at its point of launch. With 
the obvious advantage of choice of launch time 
belonging to the offense, it did not appear feasi- 
ble or economical to attempt mid-course inter- 
cepts. Consequently, we proposed that the 
intercepts be much closer to the point of impact. 
(See Figure I-3 for ICBM trajectory. ) 


Further studies indicated that the most at- 
tractive guidance method was a command system 
based on extension of the NIKE-AJAX/HERCULES 
Systems. The use of homing seemed precluded 
by the extremely high closing rate of over 5 
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Figure /-3. ICBM Trajectory 


miles per second, necessitating homing ranges 
that did not appear attainable on so small a tar- 
get as a ballistic reentry body (only one one- 
thousandth the radar size of an aircraft). The 
terminal nature of the defense also made com- 
mand guidance feasible and attractive. 


Ballistic missiles entering the atmosphere 
would suffer deceleration of up to 60 g's ai alti- 
tudes dependent on the shape of the reentry nose. 
A comparison of ballistic target characteristics 
is given in Figure I-4. The guidance problem 
and related missile maneuverability requirements 
could be eased, as proposed by Bell Laboratories’ 
Mathematical Department, through the use of 
analytical prediction of ICBM deceleration, well 
in advance of the actual high-g deceleration. 


An extensive communications network, data 
processing, computation, and tactical control 
would be necessary to the functioning of the ABM 
defense system. Local radars in the vicinity of 
the defended area and forward radars for initial 
detection would require integration with an exten- 
sive network of communications. The importance 
and complexity of fast response were emphasized 
strongly with speeds so high and reaction times 
so short that all operations would have to be 
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automatic with only the power of veto exercised 
by man. Dependence on a 10- to 15-minute 
early warning could be relatively loose and flex- 
ible, but once a target was acquired, all system 
elements would have to function as an integrated 
whole to successfully meet mission objectives. 


A major concern pointed out in this first re- 
port was the problem of separating radar decoys 
from warheads. Chaff or balloon decoys having 
high drag-to-mass ratios would be held back by 
the atmosphere and separated, but rods or jacks 
cut to the defensive radar frequency might be 
made to have approximately the same drag-to- 
mass ratio as the warheads. Rate of arrival of 
ICBMs over a target area and unresolved decoys 
could present high traffic levels requiring a tar- 
get tracking and guidance system capable of en- 
gaging up to 20 targets per minute. 


On December 28, 1955, Lt. Gen. J. M. Gavin, 
Army Deputy Chief of Staff for Research and De- 
velopment (R&D), visited Whippany for a review 
of all the NIKE programs. A somewhat shorten- 
ed version of the NIKE I status report was pre- 
sented. General Gavin was impressed with the 
study to date and gave it top priority, particu- 
larly for defense capability against ICBMs. 
Messrs. F. R. Lack, Vice President of Western 
Electric, and J. B. Fisk, Bell Laboratories 
Executive Vice President, W. C. Tinus, R. R. 
Hough, L. W. Morrison, and C. A. Warren 
were among those present at this meeting. 


Additional Defense Considerations 


On January 4, 1956, a similar NIKE I brief- 
ing was given by Mr. R. R. Hough of Bell Lab- 
oratories to the Army Policy Council. At this 
briefing, Mr. Hough responded to an Army re- 
quest for information concerning what could be 
done to provide an interim solution to the inter- 
mediate and long-range ballistic missile defense 
problem. It was pointed out that regardless of 
the approach taken, information gathering was 
the difficult part of the problem. Furthermore, 
a high level of defense was essential and a mar- 
ginal interim capability might not be worth ex- 
tensive effort. Also, any interim solution should 


be directed along lines that would lead to the 
final solution. 

A long-range, high-data-rate acquisition radar 
was essential to any ballistic missile defense 
solution, and if development could start immedi- 
ately on this critical element, a possible interim 
ICBM defense might be possible with the NIKE B 
missile and system. Mr. Hough reported that 
Bell Laboratories was currently studying the 
problem of ICBM interim capability with NIKE B 
and would report back to the Army within the next 
two months on this defense possibility. A com- 
parison of early Antiballistic Missile (ABM) 
sizes is given in Figure I-5. 


The Air Force was also interested in ABM 
defense, and in the fall of 1955, an ARDC-TR- 
56-11 technical request was made to industry for 
a 12-month ABM defense study. In this period, 
the roles and mission of the Army were defined 
as "terminal" defense and those of the Air Force 
as "area'' defense. Since the ABM concept cov- 
ered both roles, * Bell Laboratories recognized 
that any successful ABM system would have to 
combine area and terminal defense within one 
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Figure I-5. Comparative Sizes of Early ABM M. issiles 


*Area defense involved the long-range acquisition 
radars tied together by a communications net- 
work, while terminal defense involved the mis- 
siles, local tracking radars, and computers. 


integrated system approach. We therefore bid 
on the Air Force's 12-month study on the basis 
that the additional effort for the Air Force would 
be concentrated on the Forward Acquisition 
Radars (FARs) and the communications network. 
However, the results of the complete ABM study 
would be made available to both the Army and 
the Air Force. 


The Air Force study effort was for about 
$0. 5 million in comparison to more than $3.0 
million for the Army, which also covered ex- 
ploratory development. Air Force Contract 
AF33(616)-3285 with Western Electric was au- 
thorized on November 15, 1955, and was directed 
specifically to Anti-ICBM (AICBM) defense only. 
Two other defense contractors, Boeing and 
Lockheed, were among those selected in this 
Air Force competitive study. 


As the NIKE II study and the complementary 
Air Force study proceeded through the first six 
months of 1956, Bell Laboratories and Douglas 
were requested to make a number of presenta- 
tions, not only to the Army and Air Force, but 
to a number of high-level Department of Defense 
(DOD) and special defense panels as well. These 
briefings included: 
NIKE II and Study 


of Early Solution 
to ICBM Defense 


— Briefing for Dr. C. C. 
Furnas, Assistant 
Secretary of Defense 
Research and Develop- 
ment, March 30, 1956. 


— Air Force Scientific 
Advisory Board, 
May 2, 1956. 


— Presentation before 
Dr. Murphree's Anti- 
Missile DOD Defense 
Committee, . 
September 17, 1956. 


Air Force AICBM 
Weapon Study First 
Status Report 


NIKE II 


Proposed ABM System 


The defense problem and the early system 
proposed as a solution against future threats, 
including the ICBM, as presented to the Assist- 
ant Secretary of Defense for R&D on March 30, 


1956, involved a number of significant features. 
The defensive missile with the interchangeable 
noses for the air threat (seeker) or ICBM threat 
(thrust-vectoring motor for outside atmosphere) 
was proposed. (See Figure I-2.) Early acquisi- 
tion of the ICBMs would be obtained by a series 
of Forward Acquisition Radars with fan beams 
well north of the defended areas, as shown in 
Figure I-6. The overall system is illustrated 

in Figure I-7. The local high-data-rate acqui- 
sition radar shown pictorially in Figure I-~8 was 
based on the Luneberg lens antenna principle 
(Figure I-9). The possible characteristics of 
this radar are given in Table I-1. 


Table I-1 
AICBM Radar Characteristics 





120° azimuth x 
60° elevation 


Data Interval 1 sec 
Repetition Rate 120 pps 


Radio Frequency 500 MHz 


Power : 
Peak 5000 kw 
300 kW (each of two) 


Coverage 














Transmit Antenna 
Aperture 

Beam 

Gain 





2 ft x 120 ft 
60° x 1° 
27 dB 












Receive Antenna 





Aperture 120 ft diameter 
Beam I°x i 
43 dB 





Gain 
Range of ICBM 600 nautical miles 





At this same meeting, at the request of the 
Army and DOD, a possible Interim AICBM Study 
using the NIKE B missile and system was pre- 
sented. The system and guidance plan proposed 
is illustrated in Figures I-10 through I-16. 
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Figure |-6. Deployment for ICBM Defense 
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Figure |-7, ABM Battery 
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Figure !-8, AICBM Acquisition Radar 





Figure |-9. Luneberg Lens Antenna 
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Figure I-10. NIKE B System 
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Figure I-11. Mechanization of Parallel Approach for ICBM Targets 
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Figure !-12. Battery Capability vs. Target Angle 
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Figure 1-13, Variation from Nominal Intercept 


I-10 


weno 


600 


500 


> 
So 
o 


ALTITUDE (nmi) 
w 
3S 
5S 


100 200 300 400 500 600 
RANGE (nmi) 


Figure I-14, Radar Range Requirements 


CHARACTERISTICS 


FREQUENCY 4500 MHz + 250 

PEAK POWER 3000 kW 

PULSE WIDTH 3.0nSEC 

RECEIVER NF_ 7.0 dB 

ANTENNA GAIN 47 dB 

ANTENNA SIZE 20 FT DIAMETER PARABOLIC DISH 
TRACKING ACCURACY SAME AS NIKE 8 TRACK 


ESTIMATED RANGE PERFORMANCE 


RADAR CROSS 
SECTION (m?) RANGE (nmi) 
16 800 
i 400 
0.1 220 
0.01 125 


During the period of this NIKE II and Air 
Force AICBM study, there were many scientists 
in the various government agencies and in uni- | 


versities who believed it was impossible to inter- — 


cept a target going 24,000 ft/second, comparing 
it to "hitting a bullet with a bullet. '' Recognizing 
that guidance of a defensive missile to accurately 
intercept ICBMs was a challenge, an analog sim- 
ulation room used in testing the NIKE-AJAX and 
HERCULES Systems at Bell Laboratories in 
Whippany was modified to handle ICBM inter- 
cepts. After some 50,000 intercept runs under 
varying threat. parameters and intercept altitudes, 
it was convincingly demonstrated that ICBMs 
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Figure 1-15. ICBM Coverage in New York Area 


Figure 1-16. Long-Range Track Radar 


could be accurately intercepted when the guid- 
ance was properly scaled to the high-speed 
target. Furthermore, through the use of ana-~ _ 
lytical prediction tested in these simulations, 

the 60-g slowdown of the ICBM could be ade- 
quately handled by a defensive missile of much 
lower steering capability. Following a series of 
visits to Bell Laboratories by DOD and military 
groups to witness these simulations, the question 
of being able to accurately intercept an ICBM was 
no longer seriously challenged — although it was 
not until six years later that full-scale intercepts 
of actual ICBM targets were confirmed in tests at 
Kwajalein Island in the Pacific. 


I-11 


™ 
x 





Results of NIKE Il Study report, the Luneberg lens-type of acquisition 
radar was fully refined and proposed for two 


In October 1956, the results of the NIKE II , 
applications. It would be used for both the for- 


18-month study were presented in the Pentagon 


to Lt. Gen. J. M. Gavin and the Army General ward acquisition coverage called FAR and for a 5 
Staff. The final written report on NIKE I* was high-data-rate (2 seconds) Local Acquisition 
Radar (LAR) within the defended area to provide 2 


published March 1, 1957. The report included : : : 5 
both the defense against air-breathing targets hemispheric coverage and multi-tracking of 50 to i 


with a seeker-nose missile and the defense against 100 targets. The plan of integration is shown in 
ICBMs with a separable thrust-vectoring nose for Figure I-17, Artist views of the acquisition ag 
intercepts outside the atmosphere. In this final radars as proposed are shown in Figures I-18 and 

I-19 and the weapon battery in Figure I-20. The 

ICBM defensive missile shown in Figure I-21 

would carry a 400-pound nuclear warhead and pro- 


*System Study, NIKE-ZEUS Guided Missile Sys- vide 10-g maneuverability at 100,000 feet. The 

tem, Bell Laboratories Report, Vol 1 Require- a “ 

ments and Vol 2 ‘Appendices, March 1, 1957, thrust-vectoring nose would be required for end + 
(SECRET). game steering at altitudes above 80,000 feet. 
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Figure !-17. NIKE I! Plan of Integration 
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Figure I-18. Proposed Forward Acquisition Radar 


Figure |-79. Proposed Local Acquisition Radar 


I-13 


‘ 






a Zs 












2 oils 
Ah a 








Figure 1-20. Weapon Battery Installation 


In late 1956, a report on the same system was 
given to the Air Force upon completion of the 
year's study. As mentioned earlier, the addi- 
tional effort for the Air Force was applied to 
studies of the forward data gathering and on the 
communications network required for connection - 
to local defense elements. 


In reporting on an ABM communications sys- 
tem for both the Air Force and Army final 
March 1957 studies, the following general fea- 
tures were proposed: 

e The system should be completely automatic 
with all elements electronic and capable of 
operating at high speed. A communica- 
tions message -numbering plan should be 


used, based on the destination of the data 
(FAR to specific battery). 
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e The system should use intermediate 
switching to reduce the number of channels 
required for a full Continental United 
States (CONUS) defense network. 


@ Multi-alternate routing should be used to 
provide reliability. 


e Error checking should be incorporated to 
ensure accuracy in transmission. 


e Each message should be acknowledged to 
increase reliability. . 


® Voice-bandwidth channels should be used 
universally. (A proposed communication 
route was presented for defense of the , 
northeastern United States. ) 
As part of the final March 1957 report, a com- 
plete Development Test Plan for the proposed 
system was included, covering a six-year period 
from initial development to system demonstra - 
tion tests against real ICBM targets at a remote 


testing range. 
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Figure I-21. The Defensive Missile 


AICBM Report 


During the period of these studies, there was 
intense rivalry between the Army and the Air 
Force for the mission of ICBM defense. Our 
work at Bell Laboratories resulted in one system 
concept, with the additional Air Force effort 
affording an opportunity to study the overall com- 
munications network, including problems of data 
processing and data transmission. General 
Hertford of the Army had no objections to includ- 
ing appropriate parts of the results of the NIKE II 
study in our study report to the Air Force. In 
actual practice, the combined study effort proved 
somewhat embarrassing since, in presentations 
to top DOD and special antimissile committees, 
the same Bell Laboratories/McDonnell-Douglas 
system concept was presented by both the Army 
and the Air Force. 


After the AICBM report was made to the Air 
Force, they established a task group to review 
the Bell Laboratories/McDonnell-Douglas system 
and those of the other two contractors. The Air 
Force Air Research and Development Command 
(ARDC) Report of January 1957 informally indi- 
cated that they would like Bell Laboratories to 
continue their contract for another six months at 
a level of about $200,000 to cover further analy- 
sis of decoy work. Since 2a major effort on 
AICBM was continuing for the Army, the actual 
supplementary extended study for the Air Force 
was for only $90,000 directed specifically to de- 
coy discrimination. (Roles were subsequently 
redefined giving responsibility for AICBM effort 
to the Army.) 


- 


AICBM DEVELOPMENT CONTRACT — 
NIKE ll/NIKE-ZEUS 


In February 1957, the Army awarded Western 
Electric/Bell Laboratories prime contractor sys- 
tem responsibility for development of an-AICBM 
defense system and changed its name from 
NIKE II to NIKE-ZEUS. With the growing con- 
cern for the ICBM threat, Bell Laboratories 


concentrated solely on the ICBM defensive missile, 
hence terminating work on the seeker nose for 
air-breathing targets. The level of research and 
development effort for the first year was to be 
about $12 million, including subcontract work by 
McDonnell-Douglas on the missile, RCA on the 
transmitter, and Goodyear Aircraft Company 

on the antenna structure. 


Major changes were made in certain elements 
of the NIKE-ZEUS System from that described in 
the March 1957 report during the early develop- 
ment phase. 


Discrimination Radar 


One of the major research and development 
problems mentioned in both AICBM reports to 
the Army and Air Force was the task of sepa- 
rating the reentry body from the various decoys 
and junk that might accompany it. Consequently, 
research and systems work continued on this 
high-priority problem as development work on 
the overall system was initiated. The Target 
Track Radars (TTRs) in the proposed NIKE-ZEUS 
System would have to see all the objects in a cloud 
assigned to them by the Acquisition Radar and 
track one of the objects (preferably one near the 
center ofthe cloud). Atthe same time, the radar 
would have to systematically examine all received 
signals from the cloud of objects at a high data 
rate to permit a wideband frequency analysis of 
the radar return signals. The implementation for 
scanning would be such that once the reentry body 
was identified, precise automatic position and 
velocity tracking of the target would have to be 
established in a few seconds by the TTR. 


Note that at this particular time, radar 
measurements of incoming ICBMs were not 
available, since the first successful ICBMs 
were not flown until the 1959-1960 time period. 
Consequently, such discrimination possibilities 
as scintillation, radar size, and slowdown 
were proposed among other methods whose 
success might depend on the ability of the TTRs 
to obtain the high data rate mentioned. Thus, 
three methods were considered to increase 
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the angular field of radar coverage for exam- 
ining an incoming cloud: (1) scanning the 
TTR beam, (2) increasing the TTR beamwidth, 
and (3) providing additional receiver beams _ 
in the same TTR focusing structure. The 
first method was dropped, because the inter- 
mittent data would seriously limit radar data 
rate and would present a problem in tracking 
one of the objects while scanning the cloud. 
The second method of a larger beam was not 
practical because of the serious loss in radar 
range and accuracy. The third method was 
then proposed as a modification to the TTR, 
and was named the "Fly's Eye" Antenna, 


The principle of the Fly's Eye Antenna is 
shown in Figure I-22, where an array of 
antenna feedhorns is clustered about the mono~ 
pulse horns which would be used for accurately 
tracking the target after discrimination. The 
center monopulse horns would transmit and 
receive in the conventional manner. The clus- 
ter of horns located on the main reflector 
would act as range-only receivers and provide 


-a field of view of about 4-1/2 by 4-1/2 degrees, 


as shown in Figures I-23 and I-24. A separate 
transmitting antenna slaved to the large TTR 
mount would provide the illumination for the 
range-only receivers. To avoid the losses 
caused by the hole in the main reflector, a 
grating of vertical wires would be stretched 
across the horn openings and the secondary re- 
flector would be designed to shift the polariza- 
tion from horizontal to vertical. 


With these changes, and with pulse~collapsing 
chirp techniques for fine range resolution to- 
gether with multiple range-tracking circuits, 
high-data-rate signature outputs on objects ina 
cloud would be provided for radar signature and 
aerodynamic discrimination. These discrimina- 
tion circuits would accept the individual gated 
signals from the multiple range-tracking equip- 
ment and perform tests based on differences in 
amplitude, frequency spectrum, radar frequency 
sensitivity, ionization, aerodynamic-slowdown 
characteristics, etc. 
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On further study of various threat possibil- 
ities, the Fly's Eye TTR concept had the major 
drawback of having a multi-function requirement 
in a mechanical dish-type radar. Where more 
than one Reentry Vehicle (RV) was in'a cloud of 
objects, the discrimination function would have 
to be terminated once the first RV was acquired 
and precision -tracked for intercept. Fur- 
thermore, off-angle data on objects would not be 
sufficiently accurate for fast acquisition of an 
RV once it was selected for intercept. The 
decision therefore was made to have a com- 
pletely separate Discrimination Radar (DR) and 
time-share the TTRs to provide precision track 
of designated targets 6 to 10 seconds before 
intercept. 


The DR became the ZEUS System's instrument 
to select attacking warheads from debris and 
accompanying decoys. (For a full description 
of this radar, see the NIKE-ZEUS System de- 
scription in Chapter 1 of Part I.) To perform 
the discrimination functions, the DR would 
,examine a threatening cloud of objects designated 
by the Acquisition Radar. Radar returns would be 
processed by an associated DR data processor. 
The unique feature of this radar was a Casse- 
grainian-type antenna with a movable subreflector 
that permitted the radar to continuously widen its 
antenna beam and maintain cloud coverage as the 
range decreased. The radar could also provide 
angle information on all objects off the beam, so 
that defensive missiles could be launched using 
this data and, prior to intercept, the data could 
be transferred to a precision TTR for automatic 
acquisition of the designated target. The radar 
was to be designed for operation in the L-band 
with 40 megawatts of peak power from a low- 
noise maser RF amplifier. The beamwidth 
was to be continuously variable from 2 to 20 
degrees. A cutaway view of the DR antenna 
together with its range and angle coverage is 
shown in Figure 1-25. 


As proposed, the characteristics of the DR 
returns would be compared with the reentry body 
radar characteristics stored in the DR data 
processor. Velocity data obtained by tracking 
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individual objects would also be used by the data 

processor to measure the slowdown and deter- 

mine the ballistic coefficient of the objects. ; 
Requirements were established for range- 
tracking up to 100 tracks with three-coordinate 
data on 10 tracks. Later system studies of 
threat scenarios indicated a need for 3 DRs, 

6 TTRs, and 12 Missile Track Radars (MTRs) 
in a firing battery. mR 


Acquisition Radar 


The ZEUS System Study Report included a 
Forward Acquisition Radar (FAR) and a Local 
Acquisition Radar (LAR) near the firing battery. 
Further system studies, however, raised ser- 


ious questions about the defense of the FARs. ih 
Systems people raised the question that if the 
few FARS were integrated and were important a 


elements of the ICBM defense, then each should 
be defended n times as well as any of the single 
batteries associated with it (where n is the num- 
ber of batteries integrated with a single FAR). 
With the FARs located primarily in Canada, 
serious questions were raised on just how essen- 
tial the FAR installations were to the defense. - 
As a result of these studies, the FARs were 
eliminated and all search and acquisition func- 
tions were assigned to the LARs at each battery. 
The LAR design, however, was changed from a 
spherical design to a hemispherical Luneberg 
lens, as proposed for the FAR, since the hemi- 
spheric lens could be made less sensitive 

to nuclear weapon overpressure effects. 


Jn establishing the 500-MHz frequency of the 
ZEUS Acquisition Radar (ZAR) during the 18- 
month study, all important radar parameters 
known at that time and their sensitivity to fre- 
quency were taken into account. However, the 
effect from nuclear burst at very high altitude 
was not yet known. The existence of this threat 
was later shown theoretically and partially veri- 
fied by the high-altitude nuclear test program at 
Johnston Island. 


It became clear through further study that 
radar~signal attenuation due to nuclear burst 
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Figure |-25. Discrimination Radar 


effects is reduced by the square of the radar fre- 
quency. This new factor was taken into account - 
in balancing the optimum frequency of the ZAR. 
The tactical design chosen was modified for 

1000 MHz, although all prototype radars under- 
way for White Sands Missile Range (WSMR) and 
Kwajalein were left in the 450-MHz range. While 
a tactical design radar was never constructed at 
1000 MHz, design effort and manufacturing plans 
for the Luneberg lens dielectric material, re- 
ceivers, and transmitters were changed to the 
higher frequency. 


ZEUS Missile 


The missile design proposed in the 18-month 
study was to have a jethead-type nose for ballis- 
tic missile defense and an active-seeker nose for 
future air threats. With the new emphasis con- 
centrated on ballistic defense, the seeker devel- 
opment was dropped as mentioned before. The 
antimissile missile as originally proposed had 
the aerodynamic control system packaged around 
the second-stage nozzle for controlling elevons 
on the main fins entirely separate from the con- 
trol system for the jetavator motor in the nose 
section. It soon became apparent that substan- 
tial simplification could be achieved by changing 
to forward aerodynamic canard control combined 
with thrust-vectoring control. With such a change, 
two control systems were reduced to one, and all 
electronic controls would be in the nose section — 
a major simplification. 


This change, however, required that thrust 
control be obtained by exhausting the thrust 
motor's hot gases through the aerodynamic con-~ 
trol fins. Although the change greatly simplified 
the electronics and hydraulic control system, the 
problem was transferred to the mechanical de- 
signers who had to design 180-degree reversal 
exhaust systems through the fins capable of with- 
standing extreme temperatures for the 12-seéecond 
operation of the thrust motor. Many failures re- 
sulted in the step-by-step solution to this prob- 
lem, which involved complex surfaces of tungsten 
and carbon materials. In the end, a highly reli- 
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able system resulted, but not without pain to the 
McDonnell-Douglas engineers. 


Further Meetings on NIKE-ZEUS System 


A complete summary of all the presentations 


made to high-level personnel in the government 
during the development years of NIKE-ZEUS 
would fill many pages. A sample of presentations 
in 1959 is given below. 


e A NIKE-ZEUS meeting at Bell Laboratories, 
Whippany, in March 1959. The following 
people attended: 


W. A. Holaday — DOD Missile Director 
Dr. H. Skifter — DOD 

Maj. General D. E. Beach — Dept. of Army 
Maj. General W. W. Dick — Dept. of Army 


Brig. General A. J. Pierce ~ North Ameri- 
can Air Defense Command (NORAD) 


Representatives from AT&T, Western Elec- 
tric, Bell Laboratories, and McDonnell- 
Douglas. 


e Briefing for Dr. Herbert York and his DOD 
staff on April 15, 1959, in Washington, D. C. 
covering possible degradation of system cap- 
abilities in the presence of various counter- 
measures. 


e Similar meeting with presidential advisor 
Dr. James Killian's staff on April 24, 1959, 
in Washington. 


e Army Policy Committee briefing by Army and 
Bell Laboratories representatives on May 6, 
1959, in the Pentagon. 


e Lt. Gen. C. E. Hart, Commander-in-Chief of 
the Army Air Defense Command (ARADCOM) 
briefed on May 19, 1959; General E. E. 
Partridge, Commander -in-Chief of NORAD 
and Air Marshal Sleman, Deputy Commander 

‘of NORAD briefed on May 20, 1959. 


FIELD TESTING THE NIKE-ZEUS SYSTEM 


Suitable locations for field testing the high- 
performance subsystems of ZEUS and for testing 
the overall NIKE-ZEUS System represented major 
new challenges to DOD, the Army Missile Com- 
mand, and the system prime contractor. Some 
of the background in arriving at these worldwide 
test locations is briefly covered here. 


Early testing of the ZEUS missile in the fall 
of 1959 was necessary to establish the extent of 
the aerodynamic heating problem in such a 





high-velocity missile. White Sands Missile Range 
was selected for these critical tests using a mod- 
ified HERCULES missile radar for tracking. 
However, the test flights had to be limited to 
aerodynamic control below 100, 000 feet to keep 
within the 100-mile limit of the range. Of par- 
ticular concern was the very long carry range 

of heavy missile parts in case of missile failure 
when testing outside the atmosphere with the jet- 
head thrust control. 


Many presentations were made to top DOD 
R&D officials by the Army and Bell Laboratories 
showing the very low probability of any missile 
parts landing in a populated area. Some consid- 
eration was given to clearing a 25-mile extension 
of the range, but even this would not permit full 
altitude testing of the missile. A decision was 
therefore made to provide a second missile test 
site at the Naval Test Range at Pt. Mugu, 
California. A ZEUS missile track radar, guid- 
"ance computer, launching equipment, etc., had 
to be installed at Pt. Mugu to permit testing the 
ZEUS missile at high altitude outside the atmo- 
sphere. As it developed, Pt. Mugu proved to be 
a poor missile test site for ZEUS because of the 
severe range-Safety restrictions imposed by the 
Navy resulting in fail-safe delays of only a frac- 
tion of a second. This led to a number of good 
missiles being destroyed early in flight without 
obtaining any useful data. 

The importance of R&D effort and continued 
field testing for ICBM defense were given top pri- 
ority in August 1957, when the USSR announced 
that it had successfully tested an ICBM shortly 
after placing Sputnik I into orbit. It became in- 
creasingly important to ready the ZEUS System 
for tracking our own incoming ICBMs as soon as 
they became operational in the Atlantic Test Range. 
We had to learn if we could successfully track a 
reentry body through slowdown and, in addition, 
what discrimination possibilities might be real- 
ized. These were questions critical to the suc- 
cess of the ZEUS System, 
to the installation of a ZEUS Target Track Radar 
(TTR) on Ascension Island, the target area 
planned for ICBM launches from Cape Canaveral, 
Florida. At Whippany, a similar TTR installation 


Top priority was given > 
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was built simultaneously to provide a local proto- 
type for correcting design problems. 


In addition, a full-scale program was begun at 
White Sands Missile Range. This involved ZEUS 
missile firings and the installation of major com- 
ponents of the ZEUS System — the large spherical 
acquisition radar, the associated missile and 
track radars, and the ground guidance computer — 
to prove in the designs. 

Still to be found, though, was a location where 
the entire NIKE-ZEUS System could be installed 
and eventually tested against real offensive targets. 
Since this one key site had yet to be selected, it 
was temporarily referred to as "Site X.'' In 
January 1958, Bell Laboratories, Western 
Electric, and Army planners began shopping for a 
suitable location. The logical place to look was 
the Atlantic Range area, where Antigua, Barbuda, 
and Ascension were the first locations considered. 
These islands, however, were not U.S. posses- 
sions and their potential use for missile firings 
was considered too sensitive. Another location 
had to be found. General E. Dooley of the Army 
Rocket and Guided Missile Agency (ARGMA) was 
the prime mover in arriving at a suitable test site. 

Attention then shifted to the Pacific area. 
Planners pored over maps and studied data and 
photography of a dozen Pacific islands and atolls. 
As the study progressed, Kwajalein Atoll in the 
Marshall Islands began to look more and more 
attractive, for a number of reasons. 


Kwajalein was not owned by the U.S., but it 
had been under American stewardship continuously 
since 1944, Kwajalein was once a Navy base, but 
appeared headed for phaseout. Although it was 
remote, Kwajalein was still within a day's flying 
time of Hawaii; Johnston Island, another possible © 
test site, lay almost directly enroute. Most 
desirable of all, however, were Kwajalein's 
existing facilities and its geographic location. 
Kwajalein already had an airstrip, a harbor, 
housing areas, schools, a hospital, merchandis- 
ing facilities, and more. In addition, Kwajalein 
was roughly 4800 miles from the West Coast, a 
range nearly ideal for testing NIKE~ZEUS against 
ICBM targets of opportunity to be launched from 
Vandenberg Air Force Base. 


On February 12, 1959, on recommendation of 
ARGMA, supported by Bell Laboratories and 
Western Electric, DOD approved a test program 
for NIKE-ZEUS with Kwajalein as the down -range 
test site. The sponsoring Army organization 
would become a tenant on the naval base. Plans 
called for a Kwajalein-Johnston Island testing 
complex, with Jupiter Intermediate Range Ballis- 
tic Missiles (IRBMs) fired from Johnston Island 
toward Kwajalein. A year later, however, Dr. 
Herbert York (then Assistant Secretary of De- 
fense for R&D) ruled that only Air Force Atlas 
ICBMs launched from Vandenberg would be used 
as target vehicles for NIKE-ZEUS. Thus, work 
on Johnston Island was halted. With the beginning 
of operations at Kwajalein, and for a number of 
years thereafter until Ascension Island closed, 
the NIKE-ZEUS System development and test ac- 
tivities were 12,000 miles apart on opposite sides 
of the globe. 


With selection of Kwajalein, project managers, 
anxious to inspect the new site, chartered a Pan 
American DC-7 which touched down on Kwajalein 
on August 4, 1959. The 41 passengers aboard re- 
presented various Army agencies, Bell Labora- 
tories, Western Electric, McDonnell-Douglas, 
and other subcontractors. 


The initial work at Kwajalein belonged to the 
Army Corps of Engineers and their subcontractor, 
the Pacific Martin Zachry Company, who was re- 
sponsible for the NIKE-ZEUS technical building 
and launch facilities. They were followed later by 
Western Electric equipment engineers and instal- 
lers responsible for the NIKE-ZEUS installation. 
On October 1, 1960, Bell Laboratories announced 
the establishment of the Kwajalein Field Station, 
and four days later, Mr. R. W. Benfer of Bell 
Laboratories arrived as its first director. 


HIGHLIGHTS OF NIKE-ZEUS R&D 
TEST RESULTS 


ZEUS Missile Tests 
The NIKE-ZEUS System Test Program re- 


quired solution of numerous problems before suc- 
cessful intercept of live ICBM targets could be 
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accomplished, The ZEUS missile, operating in 
the lower altitude region with a peak velocity 
three times that of NIKE-HERCULES, presented 
aerodynamic heating problems even greater than 
an ICBM reentry body. During the 18-month ini- 
tial study and exploratory development effort, 
McDonnell-Douglas aerodynamic engineers car- 
ried out wind tunnel tests at high-supersonic 
velocities and heat-tested various ablative coat- 
ings such as teflon and fiberglass to protect the 
missile structure. However, the extent of the 
problem was not fully appreciated until the early 
ZEUS missiles were flown at the White Sands 
Missile Range. 


Catastrophic failure of these early flights oc- 
curred within a few seconds of the missile's 
reaching peak velocity, and ground cameras re- 
corded what appeared to be a fire aboard the mis- 
sile prior to its failure. A hydraulic oil fire was 
suspected and steps were taken to provide heat 
shields around the hydraulic power system for 
future missile flights. However, after these 
changes, fire was still observed in the nose sec- 
tion and missile failure occurred as before. It 
was not until missile pieces were recovered from 
the desert range and partially reassembled that 
the real problem was discovered, 


It was clear from examining the four control 
fins that their large-diameter hardened-steel 
shafts were sliced off by aerodynamic heating 
which resulted in loss of control and missile de- 
struction, The control fins were purposely 
shaped to have wide separation from the missile 
skin based on aerodynamic wind-tunnel data, 
After returning to the wind tunnel with much finer 
measurements of pressures under the fin surface, 
high pressure points were discovered that re- 
sulted in concentrated heat levels. On redesign, 
a teflon ramp was provided under the control fin 
giving close spacing. In addition, circular traps 
were provided to protect the control shaft, much 
like a radar engineer would design to protect the 
ball bearings in a shaft from RF power. With 
these changes, the major aerodynamic problem 
was solved, opening the way to successful ZEUS 
missile firings. This ramp design and close 














spacing for the control fins was adopted by Martin 
designers for the SPRINT missile some six years 
later. As a result, even though SPRINT's veloc- 
ity was higher at lower altitudes, with much 

greater aerodynamic heating, the same basic de- 
sign was successful in protecting its control fins. 


The other major step forward in missile de- 
sign was providing aerodynamic and thrust control 
from the same control fins. The problem of 
handling the hot gases of the third-stage motor 
through a manifold system into the control fins 
was solved by extensive ground testing with many 
configurations of tungsten and carbon materials. 
As a result, relatively few.failures of the jet con- 
trol system occurred in early flights at high alti- 
tudes from the Pt. Mugu range. 


One important lesson learned from the ZEUS 
development firings, and reaffirmed years later 
with SPRINT, is that there is no substitute for 
missile testing over a ground range where the 
pieces can be recovered and the cause of failure 
found. This is especially true where the state of 
missile art is being advanced significantly and 
where there is a limit to the number of missile- 
borne sensors capable of detecting the cause of 
failures. A summary of these early ZEUS mis- 
sile firings is given in Table I-2. 


TTR-Whippany/Ascension 


The first attempt of the TTR at Ascension 
Island to track an ICBM (Titan) fired from Cape 
Canaveral took place on March 29, 1961. This 
attempt failed because the TTR computer did not 
properly translate trajectory data from Cape 
Canaveral to position the antenna needle beam. 
However, on May 28, 1961, an ICBM from Cape 
Canaveral was tracked along its trajectory down 
the Atlantic Missile Range. These initial track- 
ing tests were not perfect, but for the first time 
they did permit analysis of target characteristics 
and measured our ability to track such high-speed 
targets. 


Concurrently, a similar TTR at Bell Labora- 
tories, Whippany, was used to investigate these 
early automatic tracking problems. On May 6, 
1961, the Whippany TTR successfully tracked the 
Echo satellite at distances up to 1400 miles. 
Later in the year, four ICBMs (two Atlas and 
two Titan) were successfully tracked by the 
Ascension TTR with continuous tracks of up to 
100 seconds. In the last tracking, the Atlas had 
a nose cone designed for NIKE-ZEUS tests at 
Kwajalein. The nose cone had the same radar 


Table I-2 
Summary of Early ZEUS Firings 
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Development Firings 


7 34 
4 10 
1 1 
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Missile Performance in System Tests 






Total 


Total Firings 





cross section as a regular Atlas nose, but it also 
had special shaping to reduce the plasma-sheath 
effect on radio signal propagation. This was re- 
quired for a radio doppler miss~distance indicator 
to be used later in system tests at Kwajalein. 


White Sands Missile Range Tests 


Initial operation of the ZEUS Acquisition Radar 
(ZAR) as a system was accomplished at WSMR 
in June 1961. Typical targets were automatically 
acquired and tracked in three dimensions. The 
targets included balloons, aircraft, parachutes 
deployed from Highball missiles, and HERCULES 
missiles. These three-dimension tracks were 
transferred to Battery Control, where they were 
automatically acquired by the TTR subsystem. 


Such tests were historic in that the ZAR was 
the first track-while-scan radar system to suc- 
cessfully cover the entire hemisphere surround- 
ing a radar position, detect the objects in that 
space, remember their past positions, and pre- 
dict where the objects would next be in three di- 
mensions — all automatically, beginning with ini- 
tial detection. Even today, considering the 
advances with phased-array radar systems, the 
ZAR represents the most efficient wired-logic 
system for detection, report sorting, track ini- 
tiation, and track processing ever developed. Its 
stacked-array receivers on three rotating arms 
also provided the highest data rate (measured 
for full hemispheric coverage) yet achieved, and 
is not mached even by today’s phased-array sys- 
tems. 


The TTR radar at WSMR was made operational 
without difficulty, based on previous testing with 
a similar design at Whippany and Ascension. The 
other major subsystem was the Battery Control 
Building, which contained two Missile Track 
Radars, the Target Intercept Computer, and data 
communication equipments. The ZEUS missile 
had been under development at WSMR for the pre- 
vious two years, using modified HERCULES 
equipment for ground guidance. 


All elements of NIKE-ZEUS were checked out 
and system demonstrations begun in November 
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1961. On December 14, 1961, a major ABM sys- 
tem milepost was passed with the successful in- 
terception by a ZEUS missile of a NIKE- 
HERCULES target missile. A second successful 
ZEUS system test against a HERCULES missile 
was carried out in March 1962. Major attention 
then shifted to the forthcoming system tests at 
Kwajalein against ICBM targets. 


NIKE-ZEUS System Tests at Kwajalein 


The entire NIKE-ZEUS System, consisting of 
the hemispheric ZEUS Acquisition Radar (ZAR), 
two Target Track Radars (TTRs), one Discrim- ac 
ination Radar (DR), three Missile Track Radars 
(MTRs), and Battery Control Equipment with ! 
Target Intercept Computer and four ZEUS launch ie 
cells, was installed on Kwajalein and ready for 
the first test of intercepting an ICBM on June 26, 
1962. The photographs in Figures I-26 and I-27 
show this installation. 


In the first attempt (probably in the world) to 
intercept an ICBM fired 4500 miles down range 
from Vandenberg Air Force Base, the ZAR 
started tracking the tank at 446 nautical miles 
and immediately transferred the track to a 
TTR. The TTR transferred from the tank to the 
nose cone (the RV) at 131 nautical miles. When 
the tank began to break up, a clutter mode of 
operation was initiated in which any significant 
departure of the RV from a predicted trajectory 
would indicate that debris had taken over the 
tracking gate. The radar would then use extrap- 
olated data to "coast" the range gate so as to re~ 
acquire the RV after it passed through the tank a 
clutter. Unfortunately, in this first test, the ° 
clutter mode did not properly indicate when 
tracking of the RV was lost. However, the ZEUS 
missile would not have achieved intercept because 
of malfunction. . ° > 


Although this first system test was a failure, 
it did emphasize the need for sound logic and re- 
liable circuitry to properly track RVs through 
severe tank clutter. This early lesson carried 
through to the current tactical SAFEGUARD Sys- 
tem tests at Meck Island, where tracking through 
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Figure I-27. NIKE-ZEUS System Installation at Kwajalein, Aerial View 
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clutter has been satisfactorily demonstrated under 
even more stringent conditions. 


The first partially successful intercept of an 
Atlas D ICBM occurred on July 19, 1962, with 
the ZEUS missile coming within 2 kilometers 
of the target vehicle at intercept. The large miss 
distance resulted from the ZEUS missile losing 
hydraulic power due to excessive roll during the 
last 10 seconds before intercept. The second 
ICBM intercept ~ this one fully successful — 
took place on December 12, 1962, with a miss 
distance well within acceptable limits. A two- 
missile salvo was planned for the first time with 
this test, but the second missile failed because 
of an instrument failure. 


Another two-missile salvo intercept of an 
ICBM was attempted on December 22, 1962. In 
this test, the first missile missed the target by 
200 meters at a range of 55 nautical miles. 
Again, dual interception did not occur because of 
a failure with the second missile. 


A summary of the live-intercept system tests 
of ZEUS, extending through November 1963, is 
given in Table I-3. Of 13 system tests, nine 
were successful, three were partially successful, 
and only the first failed. Photographs of some of 


these intercepts are shown in Figures I-28 
through I-31. 


With completion of the above live-target sys- 
tem tests and the decision not to deploy the 
NIKE-ZEUS System, no further live ICBM target 
tests were carried out. However, further tests 
under the Satellite Test Program and system 
tests against taped live targets or simulated 
ICBMs continued at Kwajalein for another year 
and a half until June 1965. 


Miss-Distance Indicator for ZEUS Tests 


Miss distance between target and defensive 
missile at the instant of commanded warhead 
burst is the principal measure of performance of 
an AICBM system. To avoid suspicion of any self- 
generated miss distance within the ZEUS System, 
considerable effort was directed at finding an 
independent miss-distance recorder for the ZEUS 
System Tests at Kwajalein. One method pursued 
involved a radioactive source in the ICBM nose 
cone and a detection system in the ZEUS missile. 
This work was carried out starting in April 1961 
on subcontract with the Giannini Control Corpo- 
ration. However, a simpler radio-doppler, — 
Miss-Distance Indicator (MDI) was adopted 


Table I-3 
Summary of Live Target Systems Tests 


Mission Number 
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6-26-62 Atlas D 
7-19-62 Atlas D 
12-12-62 Atlas D 
12-22-62 Atlas D 
2-13-63 Atlas D 
2~28 -63 Atlas D 
3-30-63 Titan I 
4-13-63 Titan I 
6-12-63 Atlas D 
1-4-63 Atlas E 
8-15-63 Titan I 
8-24-63 Atlas E 


11-14-63 Titan I 
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Figure |-28. A 75-second time exposure of the K-2 Atlas D intercept at Kwajalein on July 19, 1962. 
Picture was taken from Carlson Island (5 miles northwest of Kwajalein}. 
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Figure 1-29, View of the August 15, 1963, K-26 Titan | intercept test at Kwajalein. The ZEUS 
thrust-vector motor trail and spotting detonation (arrow) mark the successful intercept. 
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Figure !-30. A 120-second time exposure of the March 30, 1963, K-17 intercept test at Kwajalein. 
This was the first intercept test to be conducted against a Titan J-boosted target vehicle. 
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Figure I-31. Two 120-second time exposures of intercept test K-21 conducted April 13, 1963. 
Top: Overall view of test taken from Enubuj (Carlson) Island. 
Bottom: View showing successful intercept (spotting charge detonation) taken 
from Ennylabegan (Carlos) Island. 
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after its successful development by the Physical 
Science Laboratory (PSL) of New Mexico State 
University . 

Well in advance of the ZEUS System Tests in 
1960, PSL was contracted to adapt a Navy AN/US 
Q-11 radio-doppler, miss-distance measuring set 
to the environment of Highball and Speedball 
test-rocket targets being developed for ZEUS 
tests, and to extend this adaption to the ICBM 
target environment. The success of this system 
was dependent on tests carried out in December 
1961, in the Atlantic Missile Range, which proved 
that a signal from a UHF radio transmitter in a 
reentering ICBM nose cone could penetrate the 
surrounding plasma sheath. The miss-distance 
instrumentation planned required such a trans- 
mitter in the ICBM and a compatible receiver in 
the ZEUS missile. The resultant shape of the 
doppler signal telemetered to ground during inter- 
cept, when correlated to the burst-command time, 
provided an independent measurement of miss dis- 
tance. This system was made ready for the 
ZEUS Systems Tests at Kwajalein for live ICBM 
targets and provided quite accurate measure- 
ments matching reasonably well with self-gener- 
ated miss-distance numbers within the ZEUS 
equipment. 

Consideration was given to adapting the same 
MDI System for the SAFEGUARD System Tests 
on Meck. However, the cost of converting the 
signals to the new telemetry S-band, adapting the 
system to the much tougher SPRINT environment, 
and a new requirement for encrypting signals 
from missile to ground led the Army to cancel 
this effort. Independent miss distances in the 
SAFEGUARD tests were obtained from ZEUS TTR 
tracks of target and missile, combined with 
optical measurements. 


SATELLITE TEST PROGRAM 


At request of the Secretary of Defense, the 
Army was asked in early 1962 to prepare the 
ZEUS System on Kwajalein for the eventuality of 
having to intercept and destroy satellites. Bell 
Laboratories advised the Army that the ZEUS 
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System could be readied for a satellite-intercept 
demonstration at Kwajalein by May 1963. 


Toward this goal, the first DM-15B series 
ZEUS missile, modified for satellite-intercept 
tests, was fired at White Sands Missile Range 
December 17, 1962. The missile successfully 
intercepted a designated stationary space point 
at an altitude of 100 nautical miles. This missile 
reached the highest altitude of any missile 
launched at White Sands to that date. The DM- 
15S series was modified for this high-altitude, 
long-range application to include a two-stage 
(instead of a single-stage) hydraulic pumping 
unit, a high-performance Polybutadiene Acrylic 
Acid (PBAA) booster propellant, and a 5-minute 
(instead of the normal 2-minute) battery capa- 
bility. A second DM-15S series missile was 
fired at WSMR February 15, 1963. In this 
flight, intercept of space point occurred at an 
altitude of 151 nautical miles. 


The third DM-15S, the first to be tested at 
Kwajalein, was fired March 21, 1963 to intercept 
a simulated satellite target at an altitude of 112 
nautical miles. The flight was unsuccessful be- 
cause the MTR failed to properly track the mis- 
sile. A second missile was fired from Kwajalein 
April 19, 1963 to intercept a simulated satellite 
at 160 nautical miles. In this case, loss of bea- 
con return 30 seconds before intercept prevented 
proper mission completion. 


The first successful satellite intercept test 
and demonstration occurred May 24, 1963, at 
Kwajalein against a real target. The target 
was a special "Agena D" stage of the Air Force 
162A series. This target was instrumented 
with the NIKE-ZEUS single-path doppler, miss-~ 
distance measuring equipment discussed earlier, 
and a Luneberg lens for radar augmentation. 
The TTR first acquired the satellite at long 


.range, and the missile was launched after a 


period of precision tracking. A close intercept 
was achieved, well within what was expected 

to be the lethal range of the ZEUS nuclear 
warhead. 


From this time on through 1964, satellite- 
intercept missiles were maintained at Kwajalein 
with one always checked out and in a state of 
readiness. Arrangements were made by the 
Army to make a ZEUS nuclear warhead available 
if called upon for a real satellite mission. (Army 
personnel on Kwajalein would be responsible for 
launching the missile in a real defensive opera- 
tion.) Bell Laboratories and McDonnell-Douglas 
personnel went through many test runs to mini- 
mize the time required to launch such a missile. 
In addition, successful test intercepts were car- 
ried out against simulated satellites and booster 
space targets in 1964 as part of the training of 
Kwajalein test personnel. Fortunately, intercept 
and destruction of an enemy satellite were never 
ordered. After 1964, we were relieved of this 
"ready" requirement and were once more able to 
concentrate fully on the normal R&D test program. 


DISCRIMINATION AND SUPPORTING 
RESEARCH ON ZEUS PROGRAM 


As the ZEUS R&D program moved forward, 
continuing and expanded effort was carried out on 
the major problem of discrimination. To supple- 
ment its own internal effort, Bell Laboratories 
established subcontracts with Cornell Aeronauti- 
cal Laboratories (now Calspan Corporation) and 
Avco Everett Research Laboratories. The prin- 
cipal types of discrimination under investigation 
in the early 1960's were aerodynamic slowdown, 
scintillation, polarization, frequency diversity, 
short pulse, and infrared/optical. Other support- 
' ing research was concerned with blast tests to 
determine the hardness of ZEUS ground facilities, 
atmospheric effects of nuclear bursts, plasma 
studies of reentry bodies, and warhead require- 
ments. 


The Avco Everett investigation concentrated 
on infrared, visual, and ultraviolet reentry ef- 
fects and was carried out with the aid of the 
NIKE-ZEUS TTR on Ascension Island. Phase I, 
which began in early 1961, determined discrimi- 
nation criteria with simple instrumentation in a 
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DC-6 aircraft operating out of Ascension. Opti- 
cal/infrared data, particularly on wake spectra, 
were obtained on 14 of 17 ICBMs fired toward 
Ascension Island in 1961. Phase II started in 
early 1962, with more sophisticated instrumenta- 
tion in the aircraft and on the ground. This per- 
mitted target designation between the TTR and the 
optical tracker in the aircraft so that the same 
object tracked by the TTR could be correlated 
with optical/infrared data. A HERCULES missile 
track radar installed on Ascension Island tracked 
the beacon in a new WV-2 aircraft equipped with 
a stable reference platform. Positional data on 
incoming objects could then be transmitted in 
both directions between aircraft and TTR. Later 
on, the same aircraft was used at Kwajalein to 
obtain additional data. 


Although useful optical/infrared data were ob- 
tained in these tests, no solid discrimination 
criteria were uncovered to warrant adding optical 
airborne trackers to the ZEUS system. Further- 
more, in attempting to correlate radar and air- 
borne optical data, these tests forcefully demon- 
strated the practical problems of trying to 
incorporate such an airborne platform into a 
tactical system. 


In 1961, Bell Laboratories carried out analysis 
of the effects of plasma on radar observation. It 
was hoped that the plasma (ionic layer) sheath 
caused by aerodynamic heating might provide ad- 
ditional means of discrimination against decoys. 
Other work at Bell Laboratories in this time per- 
iod showed that extremely short pulses could de- 
termine the length of a target and thus provide a 
possible discriminant. 


Major effort at Cornell Laboratories in 1961 
and 1962 was directed at testing various radar sig- 
natures in the laboratory. These signatures in- 
cluded scintillation, polarization, and frequency 
diversity. Both Bell Laboratories and Cornell ex- 
amined methods ofincorporating a number of ra- 
dar signatures into a combined "likelihood" num- 
ber that would reveal if a given object was a war- 
head, since no one signature had proved powerful 





enough to do this by itself. Other work at Cornell 
Laboratories, in cooperation with the Ballistic Re- 
search Laboratory, involved a study of Atlas 
booster fragmentation with high-speed cameras. 


The discrimination studies and supporting re- 
search carried out during this period of the early 
1960's provided the basis for continued effort in 
the years ahead. The lessons learned from the 
ZEUS program proved valuable in the on-going 
R&D work for future ABM systems. 


_ ZEUS R&D TEAM 


The ZEUS R&D program was a team effort 
directed by Bell Laboratories with 24 major sub- 
contractors and 89 other subcontractors located 
in many areas of the country. There were also 
hundreds of additional suppliers who provided 
components directly to Western Electric and Bell 
Laboratories or their subcontractors. In addi- 
tion to having overall system responsibility, Bell 
Laboratories designed many of the major system 
elements. The Western Electric Company in 
North Carolina manufactured the R&D models of 
system elements designed by Bell Laboratories 
and installed, tested, and operated the R&D 
models at all test sites. 


Douglas Aircraft Company (now McDonnell- 
Douglas) was responsible for the design and de- 
velopment of the missile (less the Bell Labora- 
tories guidance unit), the launcher, and 
associated ground handling equipment. The 
major subcontractors and their areas of 
activity are listed in Table I-4. 


ZEUS MULTIFUNCTION ARRAY RADAR — 
MAR-! 

In 1960, Bell Laboratories conducted funda- 
mental investigations of phase-controlled scanning 
antenna arrays for possible application to the 
ZEUS System. The potential advantages of radars 
using such antennas as seen at that time were: 

(1) increased blast resistance capability, (2) 
greater power handling capability, (3) flexibility 


I-33 


of beam adjustment, and (4) capability of com- 
bining several functions in one radar. As dis- 
cussed further under NIKE-X in Chapter 2 of 
Part I, phased arrays with their inertialess 
beams would provide greater capability against 
the high-traffic-level threat. This consideration 
became one of the principal technical reasons 
advanced in 1963 for not proceeding with tactical 
deployment of the original NIKE-ZEUS System. 
(There were, of course, many other reasons 
apart from strictly technical considerations in 
the 1962-1964 time period for not deploying an 
ABM system. } 


In these forward-looking studies supported by 
the ZEUS Program, phased-array scanning was 
analyzed with respect to such factors as (1) ele- 
ment pattern directivity, (2) array pattern deter- 
ioration with scanning, (3) pointing-accuracy 
degradation with scan angle, and (4) frequency. 
The major steps involved in an engagement from 
acquisition of the target through intercept were 
quantitatively evaluated in terms of phased-array 


‘radar characteristics and the necessary data 


processing. 


On November 18, 1960, at Redstone Arsenal, 
Bell Laboratories representatives gave a presen- 
tation to ARGMA on the subject of phased arrays 
in a terminal defense. The purpose of the meet- 
ing was to report on the study work performed to 
date and to provide a basis for a proposal to do ex- 
ploratory phased-array work. 


Authorization to proceed with the design of 
a prototype model of a phased array, based on 
the Bell Laboratories study, was granted June 
1961. Western Electric had the prime contract 
and Bell Laboratories was responsible for super- 
vising the design. Sylvania was selected as the 
major subcontractor for detailed design of the 
prototype model and fabrication of the model to 
be installed at WSMR. Sperry Rand Univac 
was given the responsibility for a Phase I 
digital computer as well as the’ programming 
for the prototype radar. Bell Laboratories 
was also responsible for major system elements 
including the large number of solid-state RF 
amplifiers, 


Table I-4 
Major NIKE-ZEUS Subcontractors 


aaanee 


Goodyear Aircraft Corporation Akron, Ohio ZAR Receiving and Transmitting 
Antennas 


DR Antenna Mount and MTR 
Reflector 



























Armstrong Cork Company 
Dow Chemical Company 







Lancaster, = ZAR Lens Media 


Midland, Mich. 
Dallas, Tex. 









ZAR Transmitter 
Tactical Displays 
DR and TTR Transmitters 


DR and TTR Antenna Hydraulic 
Drives 


Continental Electronics Mfg. Co. 













Texas Instruments, Inc. Dallas, Tex. 


Great Neck, N, Y. 










Sperry Gyroscope Company 


Vickers, Inc. 






Waterbury, Conn. 









Narmco Mfg. Co. La Mesa, Cal. DR and TTR Antenna Reflectors 


Continental Can Co. 
Allis Chalmers 














TTR Antenna Mount 


Steel Weldments for TTR 
Antenna Mount 


MTR Antenna Mount 


Chicago, Ill. 
Akron, Ohio 










Steel Products Engineering Co. Springfield, Ohio 
St. Paul, Minn. 


Santa Monica, Cal, 









Sperry Rand Univac Target Intercept Computer 












Missile, Launcher, and Missile 
Handling Equipment 
Booster and Sustainer 





Douglas Aircraft Company 












Thiokol Chemical Co, Huntsville, Ala, 










Missile Hydraulic Power Unit 
Test Equipment 


AiResearch Mig. Co. 
Epsco West 


Beverly Hills, Cal. 
Anaheim, Cal. 


Rochester, N. Y. 
Grand Rapids, Mich. 
New York, N. Y. 










Test Equipment 
Stable Platform 


Architectural Engineering for the 
R & D program 


Stromberg-Carlson 


Lear Inc. 











Burns and Roe, Inc. 








New Mexico State University Test Targets 
Airborne Instruments Laboratories 


Cornell Aeronautical Laboratories 


University Park, N.M. 
Mineola, N. Y. 
Buffalo, N. Y. 









ZAR Antenna Measurements 















Decoy Discrimination Studies 


Infrared Decoy Discrimination 
Studies 








Avco Everett Research Laboratory | Everett, Mass. 












Palo Alto, Calif, High-Power Klystrons for 


ZAR Transmitter 


Varian Associates 
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Originally, the prototype radar was named the 
ZEUS Multifunction Array Radar (ZMAR). Al- 
though not part of the ZEUS System at that time, 
it was considered exploratory effort that might 
be phased into the ZEUS System at a later date. 
Later, the radar was referred to as MAR-I. The 
basic concept was to employ four installations to 
provide 360 degrees in azimuth; however, only 
one hardened installation was installed at WSMR 
for evaluation. Ground breaking for the MAR-I 
technical facility took place at WSMR in March 
1963. Construction of these facilities was the 
responsibility of the Army Corps of Engineers 
and their contractors. An aerial view of the 
installation is shown in Figure I-32. 


One of the important lessons learned from the 
hardware installation and test of the MAR-I radar 
sensor was the need to thoroughly test in the 


laboratory all the elements duplicated in large 
numbers in an array radar. A number of design 
faults resulting in poor reliability were uncovered 
in such elements as the Traveling Wave Tube 
(TWT) and its associated filament transformer. 
This resulted in an expensive redesign and re- 
placement program because of the large number 
of such elements involved. With this background 
of experience, designers of the later phased- 
array radars, MSR and PAR, were required to 
run exhaustive laboratory performance and re- 
liability tests on elements that were to be dupli- 
cated thousands of times in the full radar. 
Reference should be made to Chapter 8 of Part I 
on PAR, for discussion of the Limited Engineer- 
ing Development Model (LEDM) set up for this 
specific purpose at General Electric. 





Figure !-32. Aerial View of MAR-/ at White Sands Missile Range 
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The testing of the MAR-I at WSMR demon- NIKE-X R&D SYSTEM 
strated the feasibility of using a phased-array 
radar for a multiplicity of simultaneous func- 
tions, and verified the analytical predictability 
of array performance in a multifunction role. 
Among the important test results in these 
demonstrations were: 


The Secretary of Defense on January 5, 1963 
directed the priority development of an ABM 
defense system incorporating the most advanced 
components and techniques available. This new 
system was temporarily designated NIKE-X, 
pending selection of a more appropriate name, 


e Extensive external antenna pattern meas- The Army NIKE-ZEUS Project Manager was no 
urements of single beams and multiple- : 





beam clusters which closely matched assigned the task of implementing the new pro- 
both the internal antenna pattern meas- gram. Bell Laboratories, as the system's devel- 
Tenor) and tie ieee eaicvi tea troll opment director on behalf of Western Electric 1 
basic phase and amplitude data of the Company, the prime contractor, was called upon : 
ee receive and transmit antenna to redefine the system taking full advantage of the . 
e Stability and repeatability of these antenna latest technical state-of-the-art, moderated by oy 
patterns over extended time periods economic restraints of production costs and time 
e The ability to form and steer various restraints of deployment schedules. 
search, track, and discrimination beam 
clusters with desired precision 8 


e Dynamic tracking accuracy of airborne System Objectives 


end ballistic targets and: satellites In carrying out this system responsibility, 
e Absolute tracking accuracy from pre- 


cision tracking of solar microwave Bell Laboratories was to conduct studies and 

radiation. R&D work directed to this forward-looking anti- 
missile defense system which would include a 
combination of the high-performance SPRINT 
type missiles and a phased-array radar. The 
R&D Field Tests at Kwajalein, WSMR, and As- 
cension, as previously described, were to con- 
tinue essentially as planned to provide funda- 
mental information needed for the new system. 
The technical reasons for continuing development 
at this time, rather than deployment, involved a iS 
concern that the USSR could soon develop (by the od 
early 1970's) the ability to mount a high-traffic 
threat with decoys and chaff that could only be 
discriminated endoatmospherically. However, 
there were many sensitive political reasons in 
the decision not to deploy the NIKE-ZEUS System 

\ in 1963. Among these were (1) the high cost of oe 
a complete defense for the country, (2) ABM 
defense would be de-stabilizing, and (3) the de- 
fense would provide only for principal cities and aad 
industrial regions, leaving major areas of the 
country undefended. 


The system demonstrated the inherent broad 
frequency-bandwidth capability of arrays using 
time-delay steering in both the transmit and 
receive modes. It demonstrated the ability 
of microsecond switching in time and the use 
of multiple frequencies for separation of simul- 
taneous radar functions using various beam- 
cluster arrangements. An important demon- 
stration was the use of a centralized digital 
computer to control all radar functions and 
execute large-scale, real-time data processing. 
This included generation arid execution of all 
the beam forming and tracking functions, full 
automatic system control with provision for 
manual intervention, search detection and 
verification, precision tracking in range and 
angle, fault monitoring, display, and numerous 
other simultaneous and sequential system opera- 
tions. In general, these tests verified on a full- 
scale basis the satisfactory performance of a 
multifunction array radar in a real target en- 





vironment. Further information on MAR-I The basic plans for phased-array radar tests 
characteristics is given in Chapter 2 on . at WSMR to prove whether a single radar could 
NIKE-X. perform acquisition, discrimination, and track 
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of targets and defensive missiles were under- 
way in 1963. Furthermore, an advanced ABM 
study group at Bell Laboratories had shown the 
advantages of a high-acceleration, short-range 
SPRINT -type missile to defend a limited area 
when discrimination of the RV was delayed until 
it reached low altitude. Actually, by 1963, the 
basic concept of the NIKE-X System was well 
underway at Bell Laboratories with the objec- 
tive of terminal defense of the larger U.S. 
cities against the sophisticated USSR attack 
postulated for the mid-1970's. 


Already under study for NIKE-X was a much 
more powerful multifunction array radar than 
the MAR-I planned for WSMR tests. This radar, 
referred to as MAR-I, was assigned the role 
of search, track, and discrimination and was 
considered the centerpiece for city defense. 

A second smaller radar, called the Missile 

Site Radar or MSR, was proposed to provide 
multiple tracking of defensive missiles and 
short-range target tracking. Later on, as a 
result of further study involving the economics 
of ABM defense for smaller cities, the MSR 
role was increased to provide search, acquisi- 
tion, and track of incoming targets and thus 
provide autonomous operation in the defense of 
smaller cities. The long-range NIKE-ZEUS 
missile was carried over to the NIKE-X System 
concept* to supplement the short-range SPRINT 
missile. Further information on the NIKE-X 
System and the threat postulated is given in 
Chapter 2. 


SPRINT Missile Development 


On October 1, 1962, three contractors were 
given study contracts by Bell Laboratories for 
the proposed new SPRINT-type missile. When 
their proposal arrived on February 1, 1963, 





*Principal features of the NIKE-X System con- 
cept were summarized in a paper, "NIKE-X, 
Design Approach and Preliminary Description" 
which was presented at the Anti-Missile Re- 
search and Advisory Council (AMRAC) Sympo- 
sium, April 15, 1963, in Monterey, California. 
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seven technical subcommittees composed of 
representatives from Bell Laboratories, 
Western Electric, and the Army Missile Com- 
mand were appointed to examine the proposals 
and select the successful contractor for SPRINT 
development. On March 18, 1963, the Army 
announced the selection of Martin Marietta as 
the development contractor for the SPRINT 
missile. Development work was to be carried 
out in the Martin plant at Orlando, Florida; with 
initial testing of the missile at WSMR and sub- 
sequent system firings at Kwajalein. 


What followed through the next twelve years 
was the successful development and test firing 
of a most challenging missile, when viewed from 
the state of missile technology in the early 1960's. 
The SPRINT missile, with its acceleration to 
high velocity within the dense atmosphere at low 
altitudes, produced such high aerodynamic heat- 
ing that its skin surface could be cooled with an 
oxy~-acetelyne torch! There were several years 
of pure agony to the Martin and Bell Laboratories 
engineers in overcoming the many problems of the 
early flight program. However, in the end, these 
problems were overcome and a highly reliable 
SPRINT missile was available for the SAFEGUARD 
System Tests at Kwajalein. For a discussion 
of the characteristics and flight history of this 
development, refer to Chapter 9 on the SPRINT 
Missile Subsystem. 


Missile Site Radar — MSR 


Various configurations and parameters for the 
MSR were studied at Bell Laboratories. The 
agreed upon concept was an S-band, phased- 
array radar with a single transmitter or re- 
ceiver time sharing a single phase-controlled 
antenna face. The ability to change direction of 
the beam very rapidly was established as a 
requirement to provide high traffic-handling 
capability. After competitive proposals were 
received from seven companies, the Raytheon 
Company, Wayland, Mass., was awarded a 
contract for development in December 1963. 
The initial Phase I effort combined engineering 


personnel from Bell Laboratories and Raytheon 
to define the MSR in detail and highlight areas 
requiring maximum effort to meet development 
schedules. Varian Associates was selected to 
provide the high-power transmitter output tubes. 


In early 1965, a decision was made to pro- 
vide the MSR with its own data processing and 
command and control equipment to permit 
autonomous operation independent of a Defense 
Center in smaller city defense. Higher per- 
formance requirements were established for 
the MSR to carry out search, acquisition, and 
longer-range target tracking. The major 
change was a five-fold increase in average 
transmitter power. These changes were 


formulated with Raytheon in June 1965. Once 
this was done, the schedule for power-on of 

a two-face MSR (the tactical version would 

have up to four faces) on Meck Island in the 
Kwajalein Atoll was set for May 1968. An 
artist's view of the proposed tactical installation 
is shown in Figure I-33. 


The digital beam-forming and steering logic 
for the MSR was the responsibility of Raytheon. 
However, in the interest of standardization, the 
same type of hardware designed for the Bell 
Laboratories data processing equipment was 
supplied by Western Electric to meet Raytheon's 
logic requirements. Full details of the MSR 
development and performance are covered in 
Chapter 7. 





Figure I-33. Proposed Tactical MSR 
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Multifunction Array Radar — MAR-II 


The L-band MAR-I of the NIKE-X System was 
specially designed for long-range search and 
acquisition and high-data-rate coverage for dis- 
crimination. Plans were established for install- 
ing a prototype model on Kwajalein (see artist's 
view in Figure I-34), while the MSR was to be 
located on Meck Island some 25 miles away. 

The high-power requirements for MAR (100 MW 
peak and 2 to 3 MW average per transmitter face) 
dictated separate transmitter and receiver array 
faces. Two transmitter and receiver array 
faces were planned to provide 180-degree 
coverage. From the start, two possible imple- 
mentations of receiver beam-steering configura- 
tions were pursued in scale laboratory tests to 
determine which method would provide the opti- 
mum performance, consistent with high 


reliability and lowest cost. One method involved 
time delay (actually phase delay, a Board- 
Steered System — BSS) and the other was a 
Modulation Scan Array Radar (MOSAR) tech- 
nique developed by General Electric, Syracuse, 
New York as part of an R&D contract with Bell 
Laboratories. , al 


Raytheon was awarded the contract for the 
development of the high-power transmitter. A 
key requirement of the transmitter was the 
need for a long-life, broad-band TWT used in 
large numbers to meet the high-power require- 
ments. A team of tube engineers from Bell 
Laboratories’ Murray Hill Laboratory with 
experience in building long-life TWT gun struc- 
tures joined with Raytheon tube engineers in the 
development of the TWT with a goal of 50,000 
hours of life. Although the L-band TWT was 





Figure 1-34, MAR-{I Planned for Kwajalein 
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not deployed because of the later cancellation of 
the MAR-II, Raytheon later scaled the tube 
down to the PAR UHF band and supplied it to 
General Electric. As deployed in the PAR 
today, the tube is indicating a life of 50,000 
hours or more. © 


One of the features planned for the MAR-II 
was the ability to form multiple independent 
beams for search and, simultaneously, form 
separate clusters directed to different incoming 
clouds for discrimination. The transmitter 
beam width would be adjusted to match the 
receiver beam-cluster size. 


The plans for time-delay steering (the board- 
steered system — BSS) employed phase delay 
in contrast to the MAR-I real-time delay steer- 
ing. It was the BSS system that was compared to 
the MOSAR system from General Electric, re- 
sulting in a recommendation to the Army NIKE-X 
Project Office in March 1967 to drop further 
development of MOSAR and use the BSS for 
MAR-IL. The final decision was based on the 
straightforward approach of BSS and a real con- 
cern for the complexity and cost of a full imple- 
mentation of MOSAR. However, much credit 
should go to the General Electric engineers who 
developed an innovative steering system and made 
it work successfully in the laboratory reduced- 
scale tests. 


The MAR-II system costs, because of the 
high-power requirements and complexity, were 
so high that even the deployment of an R&D pro- 
totype on Kwajalein had tc be delayed in schedule 
and finally scaled down in January 1968. The 
scaled down model, referred to as TACMAR, 
was to initially leave out some of the transmitter 
and receiver modules, although these could be 
added later. However, by this time the original 
requirements for ABM defense had changed, 
as discussed below, and a less expensive Perim- 
eter Acquisition Radar (PAR) was substituted 
for MAR/TACMAR in tactical deployment plans. 
In May 1968, the TACMAR prototype objectives 
for installation on Kwajalein were changed from 
a tactical design to an R&D field-site radar 


I-40 


referred to as CAMAR (and later GUARDIAN) to 

provide basic field data on discrimination. Fur- 
ther information on the GUARDIAN/CAMAR ob- 

jectives is given in Chapter 2 on NIKE-X. How- 
ever, the project then supported by the Advanced 
Ballistic Missile Defense Agency (ABMDA), was 
cancelled in August 1969. — _ 


Data Processing System 


Early in 1963, studies were in progress on 
the requirements for the NIKE-X Data Proc- 
essing System. What was clear from the start 
was the need for high-speed calculations (up to 
30 million per second) that could be provided in 
modular equipment giving stepped capability for 
future growth. Equally important was the need 


for equipment having reliability an order of mag-: © 


nitude better than any commercial computer then 
available or planned. In reviewing the status of 
computing equipment designs with manufacturers, 
it became clear that the NIKE-X data processing 
requirements dictated a challenging new design 
approach. 


Bell Laboratories enlisted the help of UNIVAC 
and formed a joint team in the spring of 1963 to 
establish design requirements and specifications 
for the NIKE-X Data Processing System. Studies 
were made in the areas of basic hardware and 
logic, computer organization, switching and con- 
trol, displays, recording, programming, and 
fault location. Out of these studies came the 
decision that performance capability in a stepped- 
module structure and high system reliability 
could only be met by a multiprocessor design. 
Also, the basic logic integrated-circuit package 
had to meet reliability goals of 8 fits (8 failures 
in a billion hours). The Bell Laboratories De- 
vice Organization accepted the challenge of 
providing the integrated circuit to meet this 
reliability. More detailed discussion of the data 
processing equipment is given in Chapter 11 on 
the SAFEGUARD Data Processing Hardware. 


Many experts during the late 1960's, including 
a special committee of the American Academy of 
Science, reported to the Army that, in their opinion, 


ae 





a multiprocessor could not be made to meet the 
expected calculations per second (MIPS) pre- 
dicted by Bell Laboratories. In final test meas- 
urements on SAFEGUARD, MIPS were plotted 
versus processors in parallel. The curve fol- 
lowed an essentially linear line through eight 
processors and met or exceeded the performance 
predicted early in the design. The integrated- 
circuit package developed for NIKE-X, and manu- 
factured by Western Electric and three subcon- 
tractors for the SAFEGUARD program, has now 
accumulated many millions of device hours and 
shows results of reliability approaching the 

8-fit goal. , 


REENTRY MEASUREMENTS PROGRAM 


In the earlier discussion of discrimination, 
reference was made to the initial studies and 
laboratory work that included initial radar and 
optical observations at Ascension Island carried 
out during the early ZEUS program. By 1962, 
the ZEUS radar sensors were now deployed and 
operational at Ascension, WSMR, and Kwajalein, 
and an organized reentry measurements program 
was established (referred to as RMP A, B, and 
C) as part of NIKE-X R&D to cover the period 
from 1962 to 1970. The objectives of the program 
were to develop general discriminants for coni- 
cal reentry vehicles based on radar observable 
characteristics as a function of vehicle size, 
shape, and ablator material. Optical and infra- 
red sensors were also provided as part of these 
measurements. 


The Measurements Program at WSMR starting 
in 1963 included the use of the ZEUS elements, 
ZAR, TTR, and DR, as well as an infrared radio- 
meter installed on a HERCULES mount. By June 
1964, the WSMR was taking data on the first 
successful Athena test missile fired from Utah 
into WSMR. The major portion of the RMP tests 
was comprised of full-scale reentry flights 
principally into the Kwajalein Test Range. 

Special unique targets were provided by the 
NIKE-X Program, with other targets furnished 
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by the Air Force, Advanced Ballistic Reentry 
Systems (ABRES), Strategic Air Command (SAC) 
Evaluation Missions, and the Navy Polaris 
Program. 


The NIKE sensors, TTR and DR, went 
through major modifications at the end of the 
ZEUS System Tests at Kwajalein to adapt them 
to the sensor data-gathering requirements of 
RMP. For example, TTR No. 4 was changed 
from a 22- to a 40-foot antenna dish and a wide- 
band 60-MHz coherent system. (See Figure 
I-35.) In addition, an X-band receiver system 
was added to provide telemetry reception from 
NIKE-X supported RVs equipped with special 
on-board instrumentation. Similarly, the DR 
at Kwajalein was modified to include a Coherent 
Signal Processing System (CSPS) developed at 
General Electric as well as wideband recording 
equipment. 


In January 1964, a reentry physics panel was 
organized at Bell Laboratories with specialists 
in electromagnetic theory, plasma physics, gas 
chemistry, aerodynamics, and hydrodynamic 
stability to help guide the reentry field-meas- 
urements program and represent Bell Labora- 
tories in contacts with outside organizations 
having related interests. Further information 
on the RMP work is covered in Chapter 2 on 
NIKE-X. 


Nth COUNTRY THREAT 


In February 1965, at the request of the Army, 
an intensive investigation was started on possible 
modifications of the NIKE-X System and hard- 
ware concept to reflect the heightened national 
concern about the "Nth country" threat. Special 
emphasis was to be given to the evaluation of 
alternate techniques for achieving effective high- 
altitude defense against relatively unsophisticated 
attacks with deployment growth to meet sophisti- 
cated threats. In particular, other options were 
to be considered leading to a lower cost MAR-I. 
As part of this system study, the usefulness of 
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Figure 1-35. TTR 4 Antenna, showing 40-foot reflector with subreflector being readied for use in RMP B 
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VHF radars as supplementary sensors for acqui- 
sition, discrimination, or designation in defense 
against light, unsophisticated attacks, was 
investigated at Bell Laboratories. Included in 
this study was the blackout problem in the VHF 
band. 


On April 23, 1965, the major conclusions of 
this study were orally presented to Dr. Harold 
Brown, Assistant Secretary of Defense for R&D. 
A variety of radar design approaches was sum- 
marized in terms of performance, cost, and 
growth potential. The radars proposed were a 
MINI-MAR — a lower cost, reduced-performance 
array radar with potential for growth to a full- 
sized MAR — supplemented by a companion radar 
at VHF for long-range detection of sneak attacks 
that could be met by the ZEUS missile. The 
MSR was the choice for missile guidance, al- 
though S-band missile tracking radars of lower 
cost could be used. For close-in defense, 
SPRINT and MSR remained the choices. In May 
1965, following this presentation, Bell Labora- 
tories was authorized to reorient the NIKE-X 
System requirements to include certain modi- 
fications aimed at providing a more cost-~-effec- 
tive defense against a possible Nth country threat, 
in addition to the more sophisticated Soviet-type 
threats on which past NIKE-X design had been 
based. 


This was in line with Secretary of Defense 
McNamara's rising concern early in 1965 over 
the nation's vulnerability to the kind of attack 
that some less advanced country might launch. 
For this reason, it was urgent to determine 
whether NIKE-X was the most cost-effective way 
to provide an early defense against such a threat, 
or if there were less expensive ways. 


As a result of these studies, the NIKE-X con- 
cept was expanded to provide capability for a 
broad general defense of the whole continental 
United States against the full threat spectrum. 
This change was made possible by increased 
confidence that large nuclear warheads borne by 
two or more modified (for greater payload and 
range) ZEUS missiles in a barrage mode could 
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provide large volume kill capability — leading to 
the possible concept of an umbrella coverage of 
the entire country. (Only as threat sophistication 
increased to extremely hard, i.e., radiation- 
resistant warheads and RVs, would the short- 
range terminal defense be required.) As visual- 
ized at that time by the Director of Defense. Re- 
search and Engineering (DDR&E), the VHF radar 
would be a straightforward development (essen - 
tially off the shelf), and thus actual development 
effort would not have to begin until production 
was authorized. 


In October 1965, in response to a request 
from DDR&E, a quick examination of minimum 
NIKE-X hardware was made to assess a defense 
against simple first-generation Nth country 
ICBMs. This hardware consisted of 4 VHF 
radars and 12 MSR sites, with 20 modified ZEUS 
missiles at each site. Although good coverage 
against this particular threat was demonstrated 
in principle, the many limitations of such a de- 
fense concept were pointed out by Bell 
Laboratories. 


In November 1965, a new study of active de- 
fense for hardened sites was initiated by DDR&E. 
Three teams — Air Force, Advanced Research 
Projects Agency (ARPA), and NIKE-X Project — 
were to study defense systems to meet the threats 
and defense objectives defined by DDR&E. This 
initial study and many more that followed asso- 
ciated with Hardsite Defense are covered in 
Chapter 2 on NIKE-X. Itis sufficient to note 
here, that while studies were going on directed 
to light area Nth country defense, Bell Labora- 
tories was being asked to carry out studies of 
high-traffic terminal defense of our offensive 
weapons. It was during these studies that the 
concept of pitch-and-catch for the missile-launch 
phase was seriously considered. Up to this time, 
in all of our NIKE System developments, the 
requirement to be completely locked on the mis- 
sile prior to launch was considered inviolate. 
However, with the MSR inertialess tracking 
beam, it was found that SPRINT could be ac~ 
quired after launch with separations of up to 20 
nautical miles. 


To provide a suitable missile element for the 
Nth country barrage-type defense, authorization 
was received in January 1966 to start develop- 
ment work at |McDonnell-Dougias on a modified 
ZEUS DM-15C missile for this role. The missile 
payload would be increased to 2900 pounds for 
the high-yield nuclear warhead, necessitating 
larger first- and second-stage motors. The 
decision was made to use the modified DM-15C 
booster design for both the 5-second first stage 
and the 19-second second stage. The new three- 
stage ZEUS missile was expected to have a peak 
velocity of 9000 ft/sec and a range of about 300 
nautical miles. The first firing was scheduled 
for Kwajalein Island in March 1968. Fora 
discussion of the evolution of this missile into 
its successor, SPARTAN, refer to Chapter 10 
on the SPARTAN Missile Subsystem. 


As mentioned earlier, a VHF radar was being 
studied as a complementary long-range search 
and acquisition radar for Nth country defense. 

In December 1966, General Electric at Syracuse, 
New York was selected to start Phase I study 
work on this radar under contract to Bell Labor- 
atories. Called the Perimeter Acquisition Radar 
(PAR), this new development presented the Gen- 
eral Electric and Bell Laboratories team with the 
initial important system consideration of decid- 
ing on the operating frequency, VHF or UHF. 

A schedule for completing design definition by 
July 1, 1967 was established. 


An important consideration in this study was 
whether a UHF design matching the VHF per- 
formance could be realized without a substantial 
increase in cost. Cost comparisons were made 
for a UHF radar that matched the VHF perform- 
ance, -3 dB down and -6 dB down. Bell Labora- 
tories had agreed with an Institute of Defense 
Analysis (IDA) summer study in 1966 that the 
radar blackout from offensive and defensive war- 
head burst would seriously degrade a VHF radar; 
thus UHF was recommended. By April 1967, 
Bell Laboratories and General Electric had 
completed a cost comparison of VHF and UHF 
for presentation to the Army and DOD. The 
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decision was made to proceed with the planning 
for a PAR operating at UHF, but arranged so 
that initial deployment would be -6 dB down 

to minimize initial cost. However, the design 
should permit later growth to 0 dB performance 
for smaller future targets. This next phase, 
called Phase 1B, was limited to defining the 
system and developing critical components 
until such time as a deployment was author- 
ized. A full story of the PAR as finally devel- 
oped and deployed for SAFEGUARD is given in 
Chapter 8. 


1-67 STUDIES LEADING TO SENTINEL SYSTEM 


In December 1966, the Army AMC -NIKE-X 
Project Office and DOD asked Western Electric 
and Bell Laboratories to study a deployment 
model for NIKE-X designed to combine area 
defense with hardsite defense capabilities. 

This model, approved by DOD for production 
planning purposes, was officialy designated as 
"Plan I-67 Area/Hardsite Defense." The major 
objectives of the deployment were defense against 
a deliberate Chinese People's Republic (CPR). 
industrial/urban attack (countervalue) and de- 
fense against a deliberate high-level ICBM 
attack from the USSR (counterforce) aimed at 
U. S. strategic forces. In making this request, 
Secretary of Defense McNamara invited top 
executives of the Bell System to Washington on 
December 9, 1966 to ask their support and ex- 
perience in finding ways to minimize the cost of 
an ABM deployment, while providing a system of 
high reliability. This meeting was followed by 
another on December 13, 1966 involving execu- 
tives of Western Electric and Bell Laboratories 
and Dr. John 8. Foster, Deputy Director for 
Research and Engineering (R&E) with his staff 
in the Pentagon, together with General A. W. 
Betts and members of his Army staff. This 
meeting again emphasized that cost was a most 
important parameter in making the I-67 study. 


As a result of this request, Bell Laboratories 
and Western Electric initiated a six-month study 
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on January 16, 1967 to evaluate the "I-67" plan. 
The most important aspect of this study was to 
optimize system elements with the objective of 
selecting the option with the greatest cost- 
effectiveness. A three-month status report of 
this study was presented by Bell Laboratories to 
Generals I. Drewry and A. W. Betts on March 2, 
1967, and again on March 4, 1967 to Dr. John S. 
Foster, Deputy Director for R&E, DOD. A 
status report at the end of the six-month study 

of the I-67 deployment model was presented to 
Secretary of Defense McNamara on July 5, 1967 
at the Pentagon. Bell Laboratories made the 
primary presentation while AMC-NXPO pre- 
sented possible growth options for the I-67 de- 
ployment model. Secretary McNamara was 
pleased with results of the study but asked for 
turther investigation of specific questions dealing 
with growth aspects of the CPR threat and corres- 
ponding growth of the I-67 deployment model. A 
total report of the Bell Laboratories study was 
issued on July 5, 1967. 


The results of the study were strongly influ- 
enced by three conditions: (1) specific design 
threat, (2) total investment cost not to exceed 
5 billion dollars, and (3) initial operating capa- 
bility (IOC) within 54 months of a deployment 
decision, thereby limiting choice of equipment to 
NIKE-X elements. The deployment recommended 
in the I-67 study consisted of 6 PARs, one of 
which would be in Alaska, 17 MSRs, including 
one in Alaska and one on Hawaii, 480 SPARTAN 
(the new name for a modified ZEUS DM-15C with 
large payload) interceptors, and 455 SPRINT 
interceptors of which 325 would be for defense 
of Minuteman sites. Other studies, directed by 
the Secretary of Defense, were carried out by 
the Office of Director of Defense Research and 
Engineering (ODDR&E) and the NIKE-X Systems 
Office with threats and constraints changed from 
the Bell Laboratories study. 


On August 1 and 2, 1967 at Los Angeles, 
California, Mr. D. P. Ling of Bell Laboratories 
made a presentation on the I-67 deployment to 
the Defense Science Board of DOD. 
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On September 18, 1967, Secretary of Defense 
McNamara announced that production of a "light 
defense'' NIKE-X System would begin before the 
end of 1967. The "light defense" deployment 
was to include PAR, MSR, SPRINT, and 
SPARTAN. This modified system, derived from 
the I-67 study, was limited in its initial role to 
a complete area defense against a CPR industrial/ 
urban attack on CONUS, with a growth option for 
defense of certain U. S. ICBM bases against a 
USSR attack. With this decision, plans were set 
for completing the deferred development effort 
(referred to as objective budget) required to 
support the I-67 type deployment. This develop- 
ment work included design and manufacture of 
the PAR prototype, tactical test equipment, a 
tactical software control center, tactical ground 
support equipment for SPRINT and SPARTAN, 
and completion of design documentation. 


On November 1, 1967, the Department of 
Defense announced the locations of the first ten 
SENTINEL sites, which included Boston, Chicago, 
Grand Forks and other cities as shown in Figure 
3-1 of Chapter 3. Initial SENTINEL deployment 
was to consist of 6 PARs, 17 MSRs, 480 
SPARTANS, and 220 SPRINTs. This deployment 
could later grow to provide Minuteman defense 
by the addition of 208 SPRINTs, and modification 
of the hardware and software located near the 
Minuteman bases. For further details on the 
I-67 Study and the SENTINEL System refer to 
Chapter 3. 


SAFEGUARD SYSTEM 


Construction contracts were awarded by the 
Army Corps of Engineers and construction started 
for the first SENTINEL Site (PAR) at Boston late 
in 1968. Strong opposition developed, however, 
over the construction of such sites, and against 
the deployment of missiles with nuclear warheads 
for ABM defense. The old question faced with 
earlier NIKE deployments was now present to a 
much greater extent; that is, "put it in someone 
else's back yard.'' In view of this strong opposi- 
tion, the acquisition and construction of other sites 


were suspended on February 6, 1969, pending a 
review of the SENTINEL System by President 
Nixon. On March 14, 1969, President Nixon 
announced that the SENTINEL System would be 
“substantially modified" in the form of a new 
deployment called SAFEGUARD with the follow- 
ing new defense objectives: 
e First priority would be protection of our 
land-based retaliatory forces against a 
direct attack by the USSR; the complement 


of equipment was to be modified in accor- 
dance with this initial objective. 


e A growth option to provide defense of the 
U. S. against the kind of attack the CPR 
would likely be capable of launching within 
the decade. 


e Protection against the possibility of 

accidental attacks from any source. 

The SAFEGUARD deployment plan reduced 
the number of sites to 12, as shown in Figure 
I-36, and deleted most large city sites. The 
initial deployment was to proceed in two phases, 
the first to protect part of the Minuteman force, 










NORTHWEST 


WARREN AFB 





CENTRAL 
CALIFORNIA 


COSOUTHERN 
M@ICALIFORNIA 


INITIAL SITES 
O PAR 
@ usr 


and the second to complete the coverage of 
Minuteman sites and cope with more sophis- 
ticated threats. 


Between the start of SAFEGUARD in March 
1969, and the signing of the Strategic Arms 
Limitation Treaty (SALT I) with the USSR in 
May 1972, the authorized deployment went 
through a series of changes. In 1970, approval 
was given to start work on two Phase I sites, 
one near Grand Forks AFB, North Dakota, and 
one near Malmstrom AFB, Montana. Advanced 
preparation of five additional sites (Phase IZ) 
was also authorized; this was later reduced to 
advanced preparation at only two of these sites, 
for a total of four sites. The four-site plan was 
the one authorized through most of this period 
until the signing of the SALT I Agreement. 


The SALT I Agreement permitted the de- 
ployment of one ABM defense site for offensive 
forces and one for the National Command 
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Figure 1-36. SAFEGU ARD Deployment Plan, March 1969 
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Authority around Washington, D. C. With this 
agreement, the second Minuteman site at 
Malmstrom AFB in Montana, then under full 
construction, had to be terminated leaving only 
the site near Grand Forks to continue. Later, 
the government decided not to proceed with the 
SAFEGUARD defense of Washington, D.C. 


In accordance with the terms of SALT I in 
May 1972, and the subsequent Congressional 
decision not to authorize the deployment around 
Washington, D. C., the SAFEGUARD System 
consisted of the PAR and a Missile Direction 
Center (MDC), which included the MSR together 
with local and remote missile launch farms in 
the Grand Forks, North Dakota area. The sys- 
tem was under control of the Ballistic Missile 
Defense Center (BMDC) in Colorado. Under the 
SALT I Agreement, only 100 defensive missiles 
were permitted. Both SPARTAN and SPRINT | 
missiles were collocated with the MDC, while 
additional SPRINT missiles were located at 
four remote missile farms. See Chapter 4 for 
more information on the SAFEGUARD System. 


Fortunately, the changes in deployment ob- 
jectives in going from SENTINEL to SAFEGUARD 
did not require major changes in the test plans 
for Meck Island. Most important was the proving 
in of the prototype MSR with its associated soft- 
ware as an operational phased-array radar. 
Continued development firings were also required 
for the SPRINT and SPARTAN missiles. Finally, 
to integrate these elements, a full series of sys- 
tem tests was carried out to progressively 
stress system capability against live ICBM and 
IRBM targets. Software packages, which were 
built up in complexity to match the system test 
objectives (called the M-test series), were intro- 
duced until the final software package (the part 
to be tested through live ICBM tracking or in- 
tercepts) matched the tactical software installed 
in the Grand Forks tactical system. The field 
testing at Meck complemented the more exhaus- 
tive testing of SAFEGUARD software at the Bell 
Laboratories Tactical Software Control Site 
(TSCS) in Madison, N. J. Here, threat inputs 


1-47 


were introduced to match the design threat levels 
not attainable in field testing. Actual tracking 
data from the Meck tests were used in forming 
the test input tapes for the TSCS evaluations. 
Full details of the field tests at Meck and those 
carried out at the TSCS are given in Chapter 5 

on SAFEGUARD System Evaluation. 


During the SENTINEL and SAFEGUARD 
period, much thought was given to the installation 
of a PAR prototype on Kwajalein or Meck. Time 
schedules (with PAR development awaiting a 
production decision) and costs, dictated that the 
PAR prototype should be evaluated at the first 
tactical site and then turned over for tactical use 
after completion of R&D tests. Technically, a 
much more complete evaluation of the system 
could have been achieved with an installation on 
Kwajalein. However, it was also technically 
true that better evaluation of the PAR from a 
radar standpoint could be obtained from an in- 
stallation in the northern hemisphere, where 
aurora effects, ground clutter with abnormal 
propagation, and low-angle atmospheric tracking 
errors could be determined. In discussions 
with the Army and DOD, it was agreed that sim- 
ulation of PAR outputs for the Kwajalein system 
tests would be acceptable, although a larger 
deployment of SAFEGUARD would certainly have 
dictated a PAR installation on Kwajalein later 
in the program. 


Some of the key dates in the Kwajalein /Meck 
buildup of testing are given below: 


Mar. 2, 1968 — First SPARTAN development 
firing at Kwajalein. 


May 18, 1968 — Power-on achieved for Meck 
MSR. 


Oct. 8, 1968 — First software data transfer 
accomplished on satellite 
data link between Whippany 
and Meck. . 


Apr. 18, 1969 — Multiprocessor system 
demonstrated in Whippany 
SAFEGUARD Data Proces- 
Sing Laboratory in support 
of Meck tests. 


Dec. 11, 1969 — First MSR track of ICBM. 


Apr. 14, 1970 — M-1 Test Series starts at 
Meck. 

Aug. 28, 1970 — First successful intercept 
of ICBM with SPARTAN. 

Dec. 23, 1970 — First live target intercept 
by SPRINT. 

Jan. 11, 1971 — First SPARTAN Salvo. 

Mar. 17, 1971 — First SPRINT Salvo. 

Aug. 27, 1971 — First M-2 mission. 

Mar, 16, 1972 — First remote launch of 
SPRINT from Dleginni 
(about 20 miles from Meck) 
to test "toss and catch," 

May 1973 -— Revision 19 of software 
delivered to Meck for final 
M-2 Series Tests, 

Aug. 1974 — Final M-2 System Tesis. 

Apr. 1975 — Final warhead and produc- 


tion missiles fired from 
Meck — 2 SPARTANS an 
1 SPRINT. 

A capsule summary of the M Series of system 
tests is given below. The M-1 Series was to 
prove in the basic concept of the system elements 
working together, while the M-2 series evaluated 
the system against increasingly stringent target 
and system conditions. 


M-1— Concept M-2 — Final 
Verification System Evaluation 
Success 12 46 
Failure 5 (includes one 7 (includes 
due to target) three due to 
target) 


The TSCS test facility at Bell Laboratories 
in Madison, N. J. contained the full PAR and 
MDC data processing equipment and all portions 
of the analog hardware that interfaced with the 
missiles and radars at site. This facility 
accurately reproduced the software in its tac- 
tical operational environment and was indis- 
pensible in developing software relatively free 
of errors when introduced at site. A system 
exerciser for tests at TSCS and at site provided 
the means of introducing sufficient traffic capa- 
bility and related attack parameters to test the 
tactical hardware and software at the required 
SAFEGUARD design threat level. These evalu- 
ation tests, carried out during 1974 and up to 
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April 1975 at the TSCS, supplemented by the M-2 
live-target tests at Meck, provided full verifi- 
cation that the SAFEGUARD System deployed at 
Grand Forks met its performance requirements. 


The Equipment Readiness Data (ERD) for the 
Grand Forks site was met several days before 
October 1, 1974 — the scheduled-date set almost 
four years earlier. Initial Operational Capability 
(IOC) was achieved shortly after the April 1, 

1975 scheduled date, with operational missiles 
installed in their cells and full system operation 
underway, 24 hours a day and 7 days a week. 


ABM R&D SUMMARY 


The major development milestones in the 20- 
year evolution of ABM defense, beginning with 
the early studies in March 1955 and leading to a 
tactical SAFEGUARD System near Grand Forks, 
North Dakota, are shown in Figure I-37. These 
developments trace the history of the step-by- 
step advance in technology that kept the United 
States well in the forefront of ABM defense and 
led eventually to the SALT I Agreement with the 
USSR. From the initial NIKE-ZEUS System, 
which extended earlier air defense technology 
(designed to protect against the bomber) to meet 
the extreme ICBM threat of very high speed and 
small radar size, to the more advanced systems 
designed later to protect against highly sophisti- 
cated threats, a large number of truly innovative 
developments were required. These began with 
the ZEUS System, whose Acquisition Radar with 
Luneberg lens and three-dimensional automatic 
detection and tracking, together with a high- 
performance missile combining aerodynamic 
and jet control, made possible the first success- 
ful intercept of an ICBM in 1962 at Kwajalein, 
after earlier testing at Ascension, WSMR, and 
Pt. Mugu. : 


With the decision not to deploy the NIKE- 
ZEUS System, a period of four years followed 
from January 1963 to September 1967 (referred 
to as NIKE~X) in which major steps forward 
were made in ballistic missile defense technology 
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to counter the increasing complexity of the ICBM 
threat, An exhaustive program of reentry re- 
search was carried out using the ZEUS radars 
at the three test sites as sensors for data gath- 
ering. Electronic phased-array radars, which 
compared to the ZEUS mechanically -steered 
radars had inertialess antenna beams, were 
developed for multifunction applications in the 
MAR I, MAR II, and MSR Subsystems. These 
radars were the major step required to success- 
fully meet the high-traffic threat, 


A super-accelerating missile called SPRINT 
was developed to permit delayed, low-altitude 
discrimination for close-in terminal defense. 
This missile represented another major step in 
technology, since it required high-impulse, 
short-burning motors and the ability to handle 
skin temperatures about three times those of the 
ZEUS missile. The requirements for data 
processing meant yet another major advance in 
computing technology to meet the need for high- 
speed calculations (up to 30 million per second), 
multiprocessor organization, and an order-of- 
magnitude improvement in reliability of the 
basic logic circuits. Closely related to these 
advances in hardware technology and work on 
discrimination was a continuing systems engin-~ 
eering activity to determine the optimum sub- 
system arrangements and deployments to meet 
various defense objectives of the Army and the 
Department of Defense. 


The new technologies and systems approaches 
carried out in the NIKE-X period between 1963 
and 1967 were "on the shoulders" of the R&D 
ABM advances made during NIKE-ZEUS System 
development. When the Secretary of Defense 
made the decision in September 1967 to deploy 
an ABM system called SENTINEL, the major 
elements required were available from NIKE-X 
development, except for the Perimeter Acqui- 
sition Radar (PAR), which was then under study. 
Later, in March 1969, when this deployment 
was changed to provide Minuteman defense 
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under the SAFEGUARD Program, these same 
elements — then under test at WSMR and Meck 
Island — again met the defense requirements, 


One of the major contributions in the last 
seven years of the R&D program was the suc- 
cessful development of one of the most compli- 
cated real-time software systems ever con- 
ceived. Critics of ABM defense in the late 1960's 
concentrated on the software problem as being 
too complex to provide the reliability needed. 
However, the high reliability currently attained 
with the tactical system at the Grand Forks 
site, 24 hours a day, 7 days a week, is a convin- 
cing answer to such critics. Furthermore, the 
software R&D effort on SAFEGUARD produced 
a solid background of experience and knowledge 
that will be helpful in building new defense sys- 
tems in the future. 


Another major contribution of the ABM R&D 
effort, extending from the first installation of a 
ZEUS track radar on Ascension Island in 1968 to 
the present time, has been support of offensive 
weapons programs. During this period of time, 
hundreds of data packages obtained from reentry 
missions have been supplied to the Air Force 
and other DOD agencies as a byproduct of having 
the most versatile and accurate radars available 
at the test ranges. For example, during the last 
three years of operation of the MSR Subsystem 
on Meck Island, some sixty data packages were 
supplied to other agencies concerned with offen- 
sive technology. Thus, the ABM program not 
only advanced its own defense technology, but 
made important contributions to offensive tech- 
nology as well, 


Each of these developments throughout the 
20-year history of ABM activity contributed val- 
uable experience and brought new insights to the 
challenge of meeting an increasingly sophisticat- 
ed threat. The details of each of these programs 
and the lessons learned are discussed in the re- 
mainder of this report. 





sy 








Part Il. 


MAJOR SYSTEMS AND SUBSYSTEMS 





a eer 

















oa 
mt 


vd 











In the evolution of ABM defense from the early 
NIKE II studies to the present-day SAFEGUARD 
System, a number of major systems were con- 
ceived and developed to meet the ever-changing 
threat. These systems are discussed in this 
part of the report and include NIKE-ZEUS, 
NIKE-X, SENTINEL, and SAFEGUARD. In addi- 
tion, each principal subsystem used in the 
SAFEGUARD deployment is described here from 
its initial research and development to current 
configuration. 


A list of supporting reference documents is 
provided in Part IV. Additional information 
detailing SAFEGUARD System performance is 
given in a Classified Supplement to this report. 
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MAJOR SYSTEMS AND SUBSYSTEMS 


The subject areas by chapter are: 
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NIKE-ZEUS System 

NIKE-X System 

SENTINEL System 

SAFEGUARD System 

SAFEGUARD System Evaluation 
Nuclear Vulnerability and Hardening 
Missile Site Radar 

Perimeter Acquisition Radar 
SPRINT Missile Subsystem 
SPARTAN Missile Subsystem 


. Data Processing System 
. Ballistic Missile Defense Center 
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The NIKE- ZEUS System was designed to 
provide a flexible, high-level defense against 
the complete spectrum of contemporary ballis- 
tic missile threats, and to be deployed to defend 
prime areas.’* The defense at each area was 
to be completely self-contained and able to func- 
tion without external data or control. This capa- 
bility, together with a modular-type design, 
allowed the defense to be tailored in accordance 
with the importance of the defended area. The 
ZEUS concept also permitted an orderly system 
growth that could take into account changes in 
the offensive or defensive situation. While the 
NIKE-ZEUS System was capable of independent 
operation, there were provisions for the North 
American Air Defense Command (NORAD) to 
exercise overall control and for ZEUS to trans- 
mit battle summary information to NORAD dur- 
ing an attack. In addition, ZEUS was designed 
to receive early warning data from the Ballistic 
Missile Early Warning System (BMEWS) and 
other sources. 


Radar tracking data and command guidance 
were used to direct a high-performance defensive 
missile with sufficient accuracy to intercept and 
destroy an incoming warhead. Various elements 
of the system were so balanced that targets could 
be intercepted successfully at altitudes up to 
500, 000 feet and at ground ranges out to 75 


Chapter 1. 


NIKE-ZEUS SYSTEM 


nautical miles (this represented a nominal 
range for targets of a particular size, speci- 
fically 0.1 square meter, traveling at ICBM 
speeds). 


The NIKE-ZEUS System was never deployed 
tactically because, by 1963, the rapid evolution 
of the ballistic missile threat made it necessary 
to redirect development to the more advanced 
NIKE-X System. Rapid changes during the 
ZEUS development period led to divergence be- 
tween the installed research and development 
(R&D) equipment and the tactical NIKE-ZEUS 
System envisioned at the end of that period. The 
NIKE-ZEUS System described here is this envi- 
sioned tactical system; much of the equipment 
discussed thus never existed in the form de- 
scribed. Most of the R&D models used as 
examples in the text and shown in illustrations, 
however, were sufficiently representative so 
that, allowing for known differences, their — 
appearance affords a clear picture of the tactical 
system planned at that time. 


THE NIKE-ZEUS INSTALLATION. 


The envisioned tactical system would have 
appeared as shown in Figure 1-1. The planned 
tactical ZEUS installation, as shown in Figure 1-2, 


consisted of a Defense Center and at least one 
Battery, both to be located within the defended 
area, 


Defense Center 


The NIKE-ZEUS Defense Center, that part of 
the system shown in the right-hand portion of 
Figure 1-1, provided tactical control and acqui- 
sition data for as many as five Batteries associ- 
ated with it in the defense of a local area. Its 
mission was to supply multichannel track-coor- 
dinate data on ballistic targets or decoy forma- 
tions, and to select and transmit the necessary 
data and commands to the appropriate Battery. 


The ZEUS Acquisition Radar (ZAR) was the 
major element in the Defense Center. The ZAR 


al 


was a highly accurate, three-dimensional radar 
with substantial range against small targets. It 
had separate transmitting and receiving systems, 
and was able to scan 100 million cubic miles of 
space per second.’ 


The signal processing equipment at the De- 
fense Center received the ZAR output and used 
it to determine trajectories of detected objects. 
These trajectories were examined to decide 
whether the objects were threatening the defended 
area. Those judged to be a threat were auto- 
matically designated for engagement by appro- 
priate Batteries. 


Although each Defense Center could operate 
independently, there were provisions enabling 
neighboring centers to act in concert. This 











Figure 1-1. The NIKE-ZEUS Installation, Artist’s Conception 
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Figure 1-2. The NIKE-ZEUS Installation, Symbolic Block Diagram 


capability would have been particularly advan- 
tageous if two or more centers had been needed 
to defend an area. In such a case, communica- 
tion channels would have been provided for 
coordinating weapon assignment functions so 
that, if necessary, any one Defense Center could 
assume control of all area Batteries. 


Communications also would have been estab- 
lished between centers defending nearby areas 
so that the ZAR at one center could provide data 
for the Batteries at another should the ZAR at 
the latter site be put out of action. 


Battery 


The NIKE-ZEUS Battery, in the left-hand por- 
tion of Figure 1-1, comprised all the elements 
required for carrying out the engagement of an 
assigned target.’ Specifically, this included 
radars for tracking and discrimination, defensive 
missiles, and computers for all the calculations 
needed to accomplish a successful intercept. 


As indicated in Figure 1-3, the Battery was 
flexible, being composed of modular units so 
that it could be increased in size and capability 
when used to defend areas of greater importance. 
The number of missiles, radars, and computers 
for a given site could be tailored to a specific 
defense mission. 
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Each Battery had at least one Discrimination 
Radar (DR) able to track simultaneously individ- 
ual objects within a specific grouping, or cloud of 
objects, and select the threatening ones for inter- 
cept. There also were Target Track Radars 
(TTRs) for highly precise, long-range tracking of 
Small, high-speed objects to provide the data 
necessary for accurate terminal guidance of the 
defensive missile. Missile Track Radars (MTRs), 
also part of the Battery, were mounted on towers 
at the Battery Control Building (left center por- 
tion of the Battery in Figure 1-1), They tracked 
the defensive missiles and transmitted steering 
orders to them by means of a discrete multi- 
pulse code.* 


In the Battery Control Building, defensive- 
missile steering orders were generated by the 
Target Intercept Computers (TICs) from target 
and missile position data supplied by the tracking 
radars. These orders directed each missile 
along an efficient trajectory toward the contin- 
ually corrected predicted intercept and caused it 
to burst at the optimum point. Each computer 
was able to handle three separate target-missile 
combinations simultaneously. 


The Battery also contained tactical control 
and monitoring equipment to provide automatic 
assignment of appropriate guidance equipment 
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Figure 1-3, Minimum and Maximum Battery Sizes 


and missiles. In addition, there were displays 
to enable operators to monitor the automatic 
operations of the Battery with provision for man- 
ual intervention if required. 


As has been noted, the makeup of a particular 
Battery would depend upon its assignment. The 
practical minimum complement of equipment at 
a site was one Discrimination Radar (DR), three 
Target Track Radars (TTRs), two Target Inter- 
cept Computers (TICs), and six Missile Track 
Radars (MTRs). Twenty-four missiles were con- 
sidered a normal complement for this minimum 
Battery. 


Generally, the ratios of the number of differ- 
ent elements would not change as the Battery 
grew in size; however, the equipment's flexibility 
was such that this was not mandatory, and other 
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Battery compositions could be tailored to the 
ever-changing threat. Figure 1-3 shows the 
effective maximum size of the NIKE-ZEUS Bat- 
tery. Such a maximum did not represent an 
engineering limitation but rather a practical 
limit consistent with efficient operation. When 
a defense assignment required more equipment, 
additional Batteries could be used to achieve 
the desired level of defense. 


ZEUS ACQUISITION RADAR 


The surveillance function for the NIKE-ZEUS 
System was to be performed by the ZEUS Acquisi- 
tion Radar (Z AR) (Figure 1-4), ahigh-performance, 
track-while-scan radar which could search for 
targets throughout a large volume of space. The 
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Figure 1-4. R&D Model of ZEUS Acquisition Radar (Kwajalein) 


ZAR's primary function was to detect any 
object — whether alone or accompanied by others 
in a cloud - that was approaching the particular 
defended area, and then to provide the data re- 
quired for determining whether this object was 
threatening. The ZAR employed separate 
transmitting and receiving antennas which con- 
tinually rotated in synchronism about vertical 
axes to provide full 360-degree azimuth cover- 
ages. The three vertical fan-beams generated 
by these antennas provided elevation coverage 
from 0 to 70 degrees, The structures had a 
rotational rate of 3-1/3 revolutions per minute 
so that the three beams provided new data on 
each object within the ZAR's essentially hemi- 
spherical coverage every 6 seconds. The 
characteristics of the ZAR are listed in Table 
1-1. 
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Transmitting System 


Each section of the transmitting antenna 
(Figure 1~5) had a pillbox configuration to 
achieve a vertical fan-beam of coverage. Three 
sections were arranged 120 degrees apart in 
azimuth on a common rotating structure to 
provide the high data rate. Each antenna sec- 
tion was fed by a separate transmitter, with 
a 600-kilowatt average power output, located in 
the building below the antenna, 


The three transmitters could operate at different 
frequencies within the L-band. Each transmitter 
employed two wideband klystron tubes in parallel 
to obtain the required power. Chirp pulse tech- 
niques were used to collapse the long pulse em- 
ployed for maximum range performance to a much 
shorter pulse for the required range resolution. 


Peak Power 

Average power 

Pulse rate 

Pulse duration 

Duty factor 

Frequency 
Carrier 
Frequency shift 
Chirp 


Type 

Gain 

Aperture 
Beamwidth 
Angular coverage 
Diameter of fence 


Height of fence above 
pillbox aperture 


Aperture 
Beamwidth 
Number of beams 


Angular coverage 
Ground plane 


Noise figure 

Number of receivers 
Collapsed pulse width 
Angle determination 


Antenna rotation rate 
Data interval 

Hits per beam pass 
Range performance 


Range accuracy 
Angular accuracy 


Table 1-1 
ZEUS Acquisition Radar Characteristics 


Transmitter (three per radar) 


10 MW* 

600 kW* 

97.7 pps 
650 psec 
0.06 


Ten or fewer preselected frequencies between 870 and 960 MHz 


. Carrier shifts on successive pulses among the preselected frequencies 


Instantaneous output frequency changes linearly 400 kHz during each pulse 
Transmitting Antenna 


Triangular three-pillbox array 

28 dB 

80 ft by 2 ft, 6 in. (each of three) 

0.9° azimuth by 70° elevation 

Continuous in azimuth, 0° to 70° in elevation 
660 ft 


15 ft + 6 in. 
Receiving Antenna 
Rotating hemispherical Luneberg lens with three receiver horn tower 
assemblies and stationary ground plane 
41 4B 
80-ft diameter lens 
0.9° azimuth and elevation per feed cluster 


Three sets of vertical beams spaced 120° with 77 beams in each vertical 
stackf 


Continuous in azimuth, 0° to 70° in elevation 
600 ft in diameter 


Receiver 


3.5 dB (T = 720°K) 

231 for 70° elevation coverage 

4.5 psec at 3 dB : 

Azimuth: pulse-count technique 

Elevation: beam splitting (comparison of adjacent receivers) 
Overall Characteristics 


3-1/3 rpm 
6 sec 
Minimum of four (increases with elevation angle) 


600 nmi for 90% probability of generating a target report per scan 
(on a 0.1 sq m target) : 


250 yd (10) 


8 mils, elevation 
4 mils, azimuth 





*Waveguide loss between transmitter and antenna is less than 0.2 dB, therefore, essentially full 


power is radiated. 


TBased on an elevation coverage of 70°. 
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Figure 1-5. ZAR Transmitting System 


Receiving System 


The receiving system (Figure 1-6) used a 
Luneberg lens with an associated reflecting 
ground plane. The solid, hemispherical lens 


. Was constructed of thousands of polyfoam blocks, 


containing tiny metal slivers, to obtain the 
necessary variation in dielectric constant 
through the lens media. The symmetry of 


the lens permitted the formation of beams in 
all directions, while its entire structure was 
used as an aperture. An array of vertically 
stacked receiving beams (Figure 1-7) permitted 
simultaneous coverage in elevation. Three 

of these arrays were spaced 120 degrees in 
azimuth. The feed horns and associated RF 
receiver equipment required for these arrays 
were embedded in the periphery of the lens. 
This, in turn, rotated in synchronism with the 
transmitting antenna. The remainder of the 
receiving equipment was located in the receiver 
building under the ground plane... 


A simplified cutaway view of the lens media, 
horn trusses, ground plane, and drive mechan- 
ism is shown in Figure 1-8. The feed horns, 
each with its own complement of receiver front- 
end circuits, were mounted along each of the 
three horn trusses. Received signals, focused 
by the Luneberg lens and reflected by the ground 
plane, were picked up by one or more of the 
horns, depending upon the azimuth and elevation 
of the signal, The fan-type transmitting beam 
and the fan of receiving beams combined into a 
composite beam structure as illustrated in 
Figure 1-7. 





Figure 1-6. ZAR Receiving System 
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Target position information was obtained for 
elevation using monopulse, and for azimuth using 
a pulse-count technique. 


Signal Processing Equipment 


Since it was anticipated that hundreds of 
objects — perhaps as in a massed decoy attack — 
would be within the ZAR's field of view, a special 
type of signal processing equipment was associ- 
ated with the ZAR. This track-while-scan 
equipment not only had high-speed capabilities 
for processing many targets simultaneously, but 
also had special provisions for reducing its sus- 
ceptibility to saturation. The primary functions 
of the ZAR signal processing equipment (Figure 
1-9) were: (1) detection and consolidation of the 
radar returns, (2) initiation of tracks on new ob- 
jects, (3) maintenance of tracks on each object 
by comparing new position with expected position 
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Figure 1-8. ZAR Receiving Antenna, Cutaway View 
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Figure 1-9. ZAR Signal Processing Equipment, Functional Block Diagram 


based on previous data, and (4) prediction of cloud of threatening objects to a Battery, a 
impact point, the parameter used to determine point within the cloud would be designated for 
which objects were threatening. All of these func- use by a Discrimination Radar (DR) in tracking 
tions were performed completely automatically.”* the entire cloud. The function of this radar 
The Target Data Consolidator used all the was to provide sufficient information on all of 


the objects in the cloud so that non-lethal ob- 
jects could be filtered out and true targets 
identified. The DR that was installed at 


outputs from the individual receivers on the 
three horn trusses of the ZAR receiving antenna 
to detect targets and determine their positions. 


This was done by noting the truss and receiver Kwajalein is shown in Figure 1-10. 

at which a radar return was received, time at The DR was designed to cover clouds with 
which the signal was received, and azimuth diameters up to about 22 nautical miles. To 
information (from a magnetic drum mounted maintain this coverage as the cloud approached, 
below the Luneberg lens on the rotating portion the antenna beamwidth was varied, according 
of the antenna structure). Target elevation was to range, from 2.5 degrees at 500 nautical 
derived by combining the signal-amplitude data miles to 20 degrees at 60 nautical miles. This 
from three adjacent receivers with stored data beamwidth variation was accomplished through 
indicating the fixed elevation angle associated use of a movable subreflector mounted in 

with each receiver. The range, azimuth, ele- front of the main antenna reflector [see (A) of 
vation, and time items were arranged into a Figure 1-11]. The spacing between the subre- 
“report” which comprised the output signal of flector and main reflector was varied to produce 
the Target Data Consolidator. an adjustable degree of defocus, and thus width, 


of the beam. The characteristics of the trans- 
mitted beam are shown in (B) of Figure 1-11. 


DISCRIMINATION RADAR The DR transmitted long-duration, extremely 


The design of the NIKE-ZEUS System was high-power pulses because it had to track tar- 
such that when the Defense Center assigned a gets dispersed over a large area and begin its 


5 
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Figure 1-10. R&D Model of Discrimination Radar (Kwajalein) 


tracking at long ranges. To carry out the dis- 
crimination function, however, extremely high 
resolution of many objects was required. This 
was accomplished by compressing the long 
transmitted pulse in the receiver to provide 
fine range resolution and accuracy. Also de- 
signed into the DR was a system of multiple 
narrow tracking gates. These features made 
possible the separation of signal returns from 
the individual objects within the cloud for sub- 
sequent discrete analysis by data processing 
equipment associated with the DR. 


The Discrimination Radar (with its signal 
processing equipment) had to be able to desig- 
nate a target, which it had selected for engage- 
ment, to a TTR with sufficient accuracy for 
prompt and unambiguous transfer. To accomplish 
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this, the DR generated three-dimensional position 
information on the objects it designated. A mono- 
pulse receiving system provided azimuth and ele- 
vation position signals for the object in the narrow 
range gate. These signals gave target position 
with respect to the beam axis. In addition, the 
transmitted pulses of the DR and the TTR were 
synchronized to facilitate target transfer. The 
return signals in both radars were collapsed to 
0.25 microsecond to ensure that they would re- 
ceive exactly the same signal from the selected 
object. These measures enabled transfer of an 
object from the DR to a TTR (when it was pointed 
in the general direction of the eloud) within 2 
seconds. 


The characteristics of the DR are listed in 
Table 1-2. 
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(B) Characteristics of DR Beam 


Figure 1-11. Discrimination Radar 


Transmitter 


The DR transmitter generated chirp pulses of 
high peak power. This power output was deliv- 
ered from two special high-powered klystrons in 
the final RF amplifier.’ Transmitter operation 
was within the L-band with the output signal gen- 
erated in 13 preselected frequency channels over 
the entire operating range. It was planned that, 
in tactical operation, these channels would be 
used randomly, on a pulse-to-pulse basis, to 

\ provide frequency diversity. Each channel was 
crystal-controlled for frequency stability." 


Antenna 


The DR antenna [see (A) of Figure 1-11] was 
a parabolic reflector-subreflector structure 
employing a multimode monopulse feed and 
supported on a two-axis mount. The main re- 
flector was a metallic paraboloid with an added 
overlay of metal wires which acted as a polari- 
zation twister. The subreftector was a non- 
metallic hyperboloid, embedded with horizontal 
metal wires, capable of being moved continu- 
ously for 18 inches with respect to the main 
reflector. This motion defocused the beam and 


Peak Power 
Average power 
Pulse rate 
Pulse duration 
Duty factor 
Frequency 
Carrier 
Diversity 


Chirp 


Type 
Diameter 
Beamwidth 
Gain 


Angular coverage 


Radome 


RF amplifier 


Equivalent noise temperature 


(overall) 


Intermediate frequency 
Collapsed pulse width 
Angle determination 


Table 1-2 
Discrimination Radar Characteristics 


Transmitter 


40 Mw* 
78 kw* 

97.7 pps 
20 usec 
0.00195 


1270 to 1400 MHz 


Random pulse-to-pulse shift among 13 preselected frequencies over 
entire band 


Instantaneous output frequency varies linearly over 10-MHz range during 
pulse 


Cassegrainian 

22 ft 

Variable from 2.5° to 20° 

Varies from 36 dB at 2.5° beamwidth to 18 dB at 20° beamwidth 
Continuous in azimuth and 190° (-5° to +185°) in elevation 
Rigid, 47 ft in diameter 


Receiver 
Maser 
20°K 
30 MHz 


0.25 usec at 3-dB points 
Monopulse 


Range CapabilityT 


At maximum beamwidth (20°) 85 nmi at center beam 


At minimum beamwidth 


(2.5°) 


60 nmi at 3-dB points of beam (22-nmi diameter cloud coverage) 


700 nmi at center beam 
500 nmi at 3-dB points of beam (22-nmi diameter cloud coverage) 


Target Position Accuracy! 


5 yd 
10% of off-axis angle (0.4 mil minimum) 





*At the two output klystrons; losses in the guide, etc., are approximately 2.0 dB. 


TWith 0.1 sq m target. 


<6 dB S/N (at half-power points of beam). 





caused the beamwidth to change. The design of 
the focusing/defocusing system is illustrated in 
Figure 1-12. 


To obtain a narrow beam (2.5 degrees) for 
tracking at long ranges, the subreflector was 
positioned at the point where the image of the 
feed was at the focal point of the main reflector. 
In this condition, the rays were made nearly 


parallel by the main reflector and produced a 
narrow beam. Then, as target range decreased 
and the subreflector was moved in toward the 
main reflector, the image of the feed moved 
away from the focal point of the main reflector, 
causing the antenna to be defocused. When this 
occurred, the rays from the main reflector 
were divergent, and the beam was widened 


(up to a total width of 20 degrees). 
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Figure 1-12, Focusing/Defocusing System of DR Antenna 


1-13 


Receiver 


The DR used an extremely sensitive receiver 
to provide highly accurate position information 
on small objects in the target-decoy cloud. 

Maser RF amplifiers, operating at 2.5 degrees 
Kelvin, achieved a very low noise level. The 
receiver's monopulse design enabled it to provide 
simultaneous off-axis angle information on many 
objects; and its chirp circuits compressed 
(dechirped) the long transmitted pulse to 0.25 
microsecond to provide satisfactory range 
resolution, 


Data Processing Equipment 


A major portion of the data processing equip- 
ment of the NIKE-ZEUS System was associated 
with the Discrimination Radar. The function of 
this equipment was to analyze tracked objects 
and perform tests on them to determine which 
targets were threatening. These targets then 
were arranged in a list according to their "like- 
lihood" of being warheads. The DR data proces- 
sing equipment comprised the All-Target Proc- 
essor and the Discrimination and Control 
Computer. (See the section on Data Processing 
Equipment later in this chapter. ) 


TARGET TRACK RADAR 


The Target Track Radar (TTR), shown in 
Figure 1-13, was a precise , long-range, narrow- 
beam tracking radar which gathered highly accu- 
rate, continuous position data on very small, 
high-speed targets during the terminal phase of 
an engagement.” A supercooled, super-low- 
noise, solid-state maser RF amplifier was used 
in conjunction with a high-gain Cassegrainian 
antenna to receive and amplify signal returns as 
low as 110 dB below 1 milliwatt. 


The tactical TTR did not have a computer of 
its own, but was being designed to operate in 
conjunction with the Target Intercept Computer 
(TIC). However, because of testing require- 
ments, each of the R&D models of the TTR had 
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its own computing equipment which accomplished 
some of the functions that in a tactical deployment 
would have been done by the data processing 
equipment associated with the Discrimination 
Radar. In the tactical environment, the TTR 
would have made no decisions about targets, but 
would have been assigned a specific target (one at 
a time) by the TIC, based on the-information that 
computer received from the Discrimination and 
Control Computer. Characteristics of the TTR 
are listed in Table 1-3. 


Transmitter 


The TTR transmitter provided a narrow 
chirp pulse with 10 megawatts peak power. The 
transmitter consisted of a chirp generator and 
synchronizer, a low-level section, and a high- 
level section.” 


A stabilized local oscillator in the low-level 
section generated a signal at the transmitter 
carrier frequency from low-frequency crystal 
oscillators. This local-oscillator signal was 
mixed with a chirped signal for good range 
resolution even though long, high-energy pulses 
were transmitted. ; 


The high-level section of the transmitter 
provided final amplification of the pulses to be 
transmitted. This amplification was accomp- 
lished by two 5-megawatt klystrons whose outputs 
were combined. Figure 1-14 shows the klystron 
amplifier section, with the two output klystrons 
installed in their insulating-oil tanks. 


Antenna 


The TTR antenna (see Figure 1-13) was a 22- 
foot-diameter parabolic reflector-subreflector 
arrangement supported on a three-axis (eleva- 
tion, traverse, azimuth) mount, A three-axis 
mount (instead of the more usual two-axis type) 
was chosen to allow the tracking of extremely 
high-speed ballistic missile targets directly 
overhead, where the required axial velocities and 
accelerations would be prohibitive for the two- 
axis type." Under these conditions, such targets 
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Figure 1-13. R&D Model of Target Track Radar Antenna (Whippany) 











Peak power 

Average power ~ 

Pulse rate 

Pulse duration 

Duty factor 

Frequency 
Carrier 
Diversity 
Chirp 


Type 

Diameter 
Beamwidth 

Gain 

Angular coverage 


Radome 


RF amplifier 
Intermediate frequencies 


Collapsed pulse width 
Angle Determination 


Antenna 

Duplexer and waveguide 
Maser amplifier 
Circuit following maser 
Total radar system 


Target cross section 
0.1sqm 
0.01 sqm 


Angular (overall) 
Tracking jitter 
Boresight 
Mechanical error 
Data takeoff 

Range 
Tracking jitter 
Zero set 


Table 1-3 
Target Track Radar Characteristics 


Transmitter 


10 Mw* 
5 kw* 
97.7 pps 
5 usec 
0. 0005 


5500 + 250 MHz 
Random discrete changes among 50 frequencies in 500-MHz range 


Instantaneous output frequency varies linearly over 10-MHz range during 
pulse 


Cassegrainian 
22 ft 

0.6° 

48.5 dB 


Continuous in azimuth, 190° (-5° to +185°) in elevation, and +25° about 
a zero reference in traverse 


Rigid, 47 ft in diameter 
Receiver 


Maser followed by Traveling Wave Tube 


First IF: 1280 MHz 
Second IF: 30 MHz 


0.25 psec at 3-dB points 
Monopulse 


Equivalent Noise Temperatures at Antenna 
40°K 
99°K 
13°K 
45°K 
197°K 
Range Capability — 6 dB S/Nt 


580 nmi 
325 nmi 


Tracking Accuracy — 18 dB S/N! 


0.18 mil 
0.10 mil 
0.10 mil 
0.10 mil 
0.05 mil 


2 yd 
2 yd 





*At the two output klystrons; losses in the guide, etc., are approximately 2.7 dB. 
+0. 1 angular mil thermal tracking jitter occurs at about one half these ranges. 
istandard deviation tracking errors. 
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Figure 1-14, TTR Klystron Amplifier Section 


could be tracked to altitudes as low as 50, 000 
feet; ballistic missiles not passing through the 
zenith could, of course, be tracked to lower 
altitudes. 


The TTR antenna mount weighed about 150,000 
pounds and was positioned by hydraulic motors 
operating in pairs on each axis. These hydraulic 
drives provided a maximum slew rate in azimuth 
and elevation of 1.25 radians per second, and in 
traverse of 0.5 radian per second. 


Receiver 


The TTR receiver used a super-low-noise, 
solid-state maser for the first RF amplifier, 
‘ followed by a Traveling Wave Tube (TWT) for 
final amplification, The equivalent noise temper- 
ature of the RF amplifier, the most critical 
source of noise in the receiver, thereby was 
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reduced enormously. In previous radar re- 
ceivers, a receiver noise temperature of 3000 
degrees Kelvin was not unusual. (Figure 1-15 
compares graphically the performance of the 
maser receiver with other types of receivers. ) 
The overall TTR system noise temperature was 
197 degrees Kelvin." 


Data Processing Equipment 


As previously stated, the tactical TTR was 
not to have any data processing equipment of its 
own. However, those R&D models built and 
operated during the test program were equipped 
with data processing equipment to meet the test 
objectives. Each such TTR was equipped with 
a Target Intercept Computer as well as with 
peripheral equipment to provide the necessary 
interface with the computer. 


TARGET CROSS SECTION, 0.1 m2 
PEAK POWER, 10 M 
S/N, 6 dB ; 
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Figure 1-15. Comparison of Range Obtained with Maser Receiver and Other Receivers 


MISSILE TRACK RADAR 


The Missile Track Radar (MTR) provided 
position data on the defensive missile to the Tar- 
get Intercept Computer (TIC). It also transmitted 
steering, burst, and other orders from the TIC 
to the defensive missile via the radar beam. This 
radar could track the beacon-equipped ZEUS mis- 
sile to a range of 75 nautical miles with an overall 
angular accuracy of 0.2 mil. A combination of 
different pulse codes and frequencies permitted a 
particular MTR to communicate with a defensive 
missile without interfering with other missile- 
radar combinations. As many as 450 missiles 
could be under control in a defense area without 
mutual interference, The characteristics of the 
MTR are listed in Table 1-4. The MTR antennas 
of a Battery were mounted on towers that were 
part of the Battery Control Building (Figure 1-16) 
which also housed the radar equipment and the 
Target Intercept Computers. 


Transmitter 


The MTR transmitter provided a peak power 
output of 300 kilowatts. It consisted of a hardtube 
modulator driving a magnetron that was automat- 
ically tuned to any one of nine fixed frequencies 
spaced at 50-MHz intervals. The transmitter 
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could be switched to any of these nine separate 
ZEUS missile receiver frequencies quickly and 
accurately. An automatic frequency control unit 
referenced the transmitter signal to the X-band 
harmonic outputs of a transistorized, crystal- 
controlled frequency standard.'® 


The MTR transmitter was installed below the 
antenna in the Battery Control Building, rather 
than in the rotating structure, to keep the size of 
the rotating portion of the antenna mount to a 
minimum. RF power was fed to the antenna via 
X-band waveguide and two rotary joints, one in 
the azimuth axis and the other in the elevation 
axis. The waveguide was pressurized to 35 
pounds per square inch absolute to prevent 
breakdown and thus ensure full power output. 


Antenna 


A 4-foot-diameter Cassegrainian antenna 
(Figure 1-17), on a two-axis mount, provided a 
gain of 38 dB. The mount could rotate continu- 
ously in azimuth and track in elevation from 11.5 
degrees below the horizon through the zenith to 
11.5 degrees below the horizon on the opposite 
side. The slew rate in each axis was about 2 
radians per second. Only 5 seconds was required 
from the end of an engagement for the radar to 
lock on to the next missile. 





Peak power 
Average power 
Pulse rate 


Pulse duration 
Duty factor 
Frequency 


Type 

Diameter 
Beamwidth 

Gain 

Angular coverage 


Frequency 

Noise figure 
Intermediate frequency 
Angle determination 


Angular (per coordinate) 
Tracking jitier 
Boresight 
Mechanical error 
Data takeoff 

Angular (overall) 

Range 
Tracking jitter 
Zero set 


Table 1-4 
Missile Track Radar Characteristics 


Transmitter 


300 kw* 
108 W* : 


Normal: 162.8 groups per sec (9 pulses in éach group 
Burst: 488.4 groups per sec (4 pulses in each group) 


0.25 usec 
0. 00036 
8525 to 8925 MHz 


Cassegrainian 

4 ft 

2° 

38 dB 

Continuous in azimuth and 203° (-11.5° to +191. 5°) in elevation 


Receiver 


8960 to 9600 MHz 
9 dB 

25 MHz 
Monopulse 


Tracking Accuracy — 26 dB S/N 


0.10 milt 
0.10 milt 
0. 10 mil} 
0.05 milt 
0. 18 mil 


2 yat 
2 yal 





*At magnetron; losses in the guide, etc., are approximately 2 dB. 
tNominal value obtained at maximum design range. 
Istandard deviation tracking accuracy. 
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Figure 1-16. Battery Control Building with Missile Track Radar Antennas 





Figure 1-17. R&D Model of MTR Antenna (Whippany) 
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Receiver 


The MTR's monopulse receiver had a noise 
figure of 9 dB and a bandwidth of 10 MHz, It 
could be automatically tuned to any one of the 
nine fixed frequency channels used by ZEUS 
missile transmitters; these channels were 
spaced at 80-MHz intervals. 


The signals from the missile transmitter, 
intercepted by the MTR antenna, were fed to a 
comparator which converted the horn inputs to 
azimuth, elevation, and sum signals. These in 
turn were fed to a converter assembly, where 
they were mixed with the local oscillator output 
to produce IF signals. The local oscillator 
was a klystron, the frequency of which was 
controlled to within +3 MHz by an automatic 
frequency control system, thus locking the 
receiver to the signals from the missile. 
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JET NOZZLE 


JETHEAD 







> CONTROL MECHANISM 
: JETHEAD MOTOR 


The gains of the sum, azimuth, and elevation 
channels of the receiver always had to be kept 
equal to preserve interchannel balance, even 
though the received signals may have had amp- 
litudes varying over a range of 94.5 dB. This 
automatic gain control was achieved through the 
use of transistorized digital-amplifier and atten- 
uator-switching circuits, which could adjust 
gain in 1.5-dB steps. The range unit in the 
receiver also employed transistorized circuits 
and digital techniques in furnishing data to the 
Target Intercept Computer. Azimuth and eleva- 
tion angle data were derived from precison 
resolvers on the two antenna axes and were en- 
coded for transmission to the computer. 


MISSILE 


The NIKE-ZEUS missile (Figure 1-18) had 
three major sections — the booster or first stage, 


HYDRAULIC PUMPING UNIT 
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Figure 1-18. NIKE-ZEUS Missile, Cutaway View 
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the sustainer or second stage (also called the By 
mainstage), and the nose section or jethead.” To 

avoid additional complexity, the same missile- 

borne guidance and control equipment was used - 
to position the missile's control surfaces both 

inside and outside of the atmosphere. Within the 
atmosphere, roll control and steering were ac- 
complished by aerodynamic forces acting on four 

control fins. Outside the atmosphere, reaction = 
control was used, with the gases expelled through 
jet nozzles in the same control surfaces. Figure 

1-19 shows the NIKE-ZEUS missile ready to 

launch. Missile characteristics are given in 

Table 1-5, 


a 
= 


The missile-borne guidance unit, shown in 
Figure 1-20, received and decoded the steering 
orders and certain commands, such as arm and 
burst, relayed to it by the MTR.” These coded 
instructions were received as groups of pulses 
modulating a carrier whose frequency was in the 
range from 8525 to 8925 MHz. The guidance unit os 
comprised a transmitter, a receiver, a decoder, 
a stable platform, part of the missile's autopilot, 
and several on/off circuits. There were four 
identical antennas spaced at 90-degree intervals 
on the outer housing of the guidance unit and en- 
closed in strakes (see Figures 1-18 and 1-19). 

Each antenna was a cylindrical waveguide ter- 
minated in a diverging lens to give hemispherical 2 
coverage. Two of the antennas were used for 
transmitting and all four were used for receiving. 








To prevent interference among the MTR- © 
missile combinations in a Battery, a different 
combination of carrier frequency and pulse code 
was used for each missile. The missile's re- 
ceiver had a dual Traveling Wave Tube RF 
amplifier and a dual crystal detector, each 
channel being used for the signals from two of 
the missile's antennas. 





Figure 1-19. NIKE-ZEUS Missile in Launch Pit 
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Table 1-5 
NIKE-ZEUS Missile Characteristics es 





Overall 


Length (including booster) 50 ft, 2 in 
Gross Weight 24,200 Ib 
Payload 468 lb 


Booster 


Length 17 ft, 6 in 

Diameter 34 in 

Gross weight 12,900 lb 

Solid propellant Polybutadiene acrylic acid (PBAA) 


Sustainer 


Length 15 ft, 2 in 
Diameter 36 in 

Gross weight 8, 250 Ib 

Solid propellant PBAA 

Ablative covering Phenolic nylon skin 
Maximum skin temperature 600° F 

Maximum operating altitude 84, 570 ft 


Jethead 


Length (including probe) 17 ft, 6 in 
Diameter (maximum) 36 in 
Gross weight 3050 Ib 


Solid propellant (jethead 
motor) PBAA 


Ablative covering Phenolic nylon skin 
Steering and roll control: 
Within atmosphere 4 control fins 


Outside atmosphere Motor exhausting through fin 
nozzles 


Warhead section: 
Tactical missile Warhead and arming 
R&D missile Telemetry 
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Figure 1-20. ZEUS Missile-Borne Guidance Unit 
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DATA PROCESSING EQUIPMENT 
Functional Organization 


Data processing equipment in the NIKE-ZEUS 
System was concerned with processing position 
information from the radars, planning and con- 
trolling system operations (tactical control), and 
accomplishing target selection and decoy discrim- 
These functions were implemented by 
six major computing equipments, as illustrated 
in Figure 1-21, pius associated peripheral 
equipment.” 


ination. 


The Target Data Consolidator detected targets 
and determined their positions.” The ZAR Data 
Processor evaluated the threat and provided data 
on threatening objects to the Batteries, where 
appropriate Battery elements would be assigned 
to engage each target. This target information 
also was to be used by the Batteries to determine 
(1) when to fire defensive missiles and (2) what 
command-guidance orders should be given during 
the early stages of missile flight. The ZAR Data 
Processor was to have a capacity of several 
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hundred tracks depending upon the size of the 
NIKE-ZEUS installation. 


The All-Target Processor was a special- 
purpose digital computer which could process 
data on as many as 625 objects in a target-decoy 
cloud. These data were received from the Dis- 
crimination Radar in analog (video) form and 
were encoded into digital form by the processor. 
The All-Target Processor then used the slow- 
down, scintillation, and cross-section charac- 
teristics of the objects to eliminate obvious 
decoys. Data on the remaining objects were 
passed to the Discrimination and Control Com- 
puter, where additional and more rigorous dis- 
crimination tests were performed. 


The Discrimination and Control Computer 
could accept data on as many as 50 targets from 
the All-Target Processor. This computer also 
used the slowdown, scintillation, and cross- 
section characteristics of the objects to eliminate 
The 
computer then generated a composite likelihood 


those that had the characteristics of decoys. 
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Figure 1-21. Major Computing Equipments of NIKE-ZEUS, Simplified Block Diagram 
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ratio for each remaining object. The likelihood 
ratios, along with acceleration, velocity, and 
position data on all the remaining objects, were 
sent to the Battery Control Data Processor where 
the final determination for engagement was made. 


Signal flow at the Battery is shown on Figure 
1-22, Selections of Missile Track Radars and 
Target Track Radars for a given engagement 
were made by the Battery Control Switching 
System, at the direction of the Target Intercept 
Computer. The timing for all Battery units 
was provided by the Battery Timing Generator 
and communication with the Defense Center 
was via the Communications Terminal. The 
Battery Assignment Monitor and Console 
Displays provided the required man/machine 
interface. 


The Battery Control Data Processor was 
designed to perform the tactical control opera- 
tions required by the Battery primarily in an 
engagement involving decoys. Its functions 
were to include engagement planning (that is, 
how many missiles to launch, on what trajec- 
tories, and at what time) and engagement execu- 
tion (that is, which object or objects to inter- 
cept). This equipment received position and 
target-likelihood data from the Discrimination 
and Control Computer and provided target- 
designation, engagement, and equipment-request 
signals to the Target Intercept Computers. 


The Target Intercept Computer made all the 
computations required to determine the guid- 
ance orders enabling the defensive missile 
to intercept a hostile target. Each Target 
Intercept Computer handled the computations 
required for six separate concurrent engage- 
ments by time-multiplexing in one circuit path. 
The computing cycle was divided into six equal 
periods, each handling all computations for an 
engagement. The Target Intercept Computer 
utilized Missile Track Radar information on 
the position of the ZEUS missile; it also re- 
ceived target position information from the 
ZEUS Acquisition Radar, the Discrimination 
Radar, or the Target Track Radar. From this 


1-26 


information, it computed and generated coded 
acceleration orders for the Missile Track Radar 
to transmit to the defensive missile. During a 
normal interception, it generated a "jet ignite” 
command io start the jethead motor and a "burst" 
command when the ZEUS missile reached the 
point on its trajectory which produced the maxi- 
mum kill probability. Besides generating guid- 
ance orders, the Target Intercept Computer's 
functions included (1) performing certain compu- 
tations needed by the Target Track Radar and 
(2) furnishing engagement data and status infor- 
mation to the Battery Control Data Processor. 
Figure 1-23 shows the Target Intercept Com- 
puter; its characteristics are given in Table 1-6. 


Modular Structure 


In the NIKE-ZEUS System (as in the succes- 
sor systems) it was planned that the data proc- 
essing equipment be completely modular. The 
equipment was constructed of a hierarchy of 
"building blocks, " used in the numbers and 
combinations required to accomplish specific 
functions. 


The largest building block was the NIKE-— 
ZEUS High-Speed Digital Computer (Figure 1-24). 
Each of the major computing equipments shown 
in Figure 1-21 used at least one of these com- 
puters, Next below the level of the digital 
computer was the D-unit (Figure 1-25), the unit 
of replacement for field maintenance. D-units 
were sSlide-mounted in special racks. Each 
D-unit was composed of flat, chassis-like assem- 
blies called C-planes (Figure 1-26). C-planes 
were stacked vertically (up to a maximum of six) 
to form a D-unit. 


The lowest-unit building blocks were the A- 
and B-modules, The basic A-module (Figure 
1-27) contained four transistor inverters, which 
could be connected externally to form double 
inverters, flip-flops, and other logic elements. 
A-modules were arranged in an array seven 
modules wide by ten modules long on the C-plane. 
Special packages, in multiples of the A-module 
size, were referred to as B-modules, 
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Target Intercept Computer 


Figure 1-23. 
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Table 1-6 

Target Intercept Computer Characteristics 

Type of logic Resistance~coupled transistor 
logic 

Type of arithmetic Two's complement 
Type of operation Parallel 
Word length 25 bits including sign and parity 
Number representation Fractional 


Instruction repertoire 54 instructions 
Modes of operation Assigned, ready, and off-line 


Arithmetic Unit 

A-register 24-bit double rank 
Q-register 24-bit double rank 
N-register 24-bit single rank 
Speed of operation 

Addition and subtraction 2.5 usec 

Multiplication 7.5 usec 

Division 15.0 psec 

Square root 27.5 psec 


Storage 


Permanent memory 
Capacity 24,576 25-bit words 
Type of read-out Nondestruct 
Cycle time 2.5 usec 
Variable memory 
Capacity 4,096 25-bit words 
Type of read-out Destruct 
Cycle time 2.5 usec 
Reference memory 
Capacity 15 16-bit words 
Type of read-out Destruct 
Cycle time ~ 1.25 usec 
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Figure 1-25, D-Unit for NIKE-ZEUS Computer 
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Figure 1-27, Logic A-Module for NIKE-ZEUS Computer 
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In addition to the standard A-module inverters, 
some 35 special-purpose circuits were required. 
Among these circuits, which took up only about 
10 percent of the equipment, were sense ampli- 
fiers, inhibit generators, current generators, 
relay drivers, delays, and dummy loads. 
Wherever possible, these circuits were built into 
the basic A-module package. 


Another important feature of the modular units 
making up the NIKE-ZEUS data processing equip- 
ment was the diffused-base germanium transistor 
(designated 2N559) used in the logic circuits. 

This device was developed for NIKE-ZEUS by 
Bell Laboratories and produced in large numbers 
by the Western Electric Company. Major empha- 
sis was placed on providing the high degree of 
reliability needed by the system; a demonstrated 


reliability of only eight failures in 109 hours was 
achieved, 


Stores 


Three independent data processing stores 
were included in the NIKE-ZEUS System: 
(1) apermanent memory called a program store; 
(2) a variable memory called operand store; and 
(3) areference memory called reference control 
store. Characteristics of these stores are given 
in Table 1-6. 


The program store consisted of twistor wires 
and program cards containing a pattern of small 
vicalloy magnets.” As shown in Figure 1-28, 

a twistor is made up basically of a conductor 
around which is helically wrapped a strip of 





Figure 1-28. 
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Twistor Wire 








Poieeh Sage 


magnetic material. (The picture shows a greatly 
enlarged model of a twistor wire.) This material 
has a square-loop B-H characteristic, and the 
application of a magnetic field to a twistor 
element switches it from one magnetic state to 
another. Such a change of magnetic state induces 
readout current in the conductor. If a relatively 
strong external magnetic field is maintained on 
the twistor element, this element becomes mag- 
netically saturated and readout results in a 
"zero, 't Stored programs or constants can be 
set up in an array of twistors; a "zero" readout 
is obtained by placing a permanent magnet near 
each twistor element, and a "one" is obtained 
without the magnet, A 48-word variation of the 
program store was called the twistor input 
switch. Storage slots in this equipment were 
similar to those in the program store, but the 
permanent magnets were replaced by direct- 
current solenoids. 


The twistor type of memory (see Figure 1-29) 
was developed by Bell Laboratories specifically 
for NIKE-ZEUS computers. It has the advantages 
of (1) high operating speed, (2) readily changeable 
programs, and (3) the capability of a high rate of 
manufacture at low cost. A system of automatic 
memory-card production was devised; the pro- 
gram was prepared in symbolic form and the pro- 
gram cards were produced by a special machine. 
Twistor arrays also were used for switching in 
the NIKE-ZEUS System. 


1-33 





Figure 1-29. Twistor Store 


The operand store was used to store data tem- 
porarily during calculations. Ferrite cores were 
used for the storage elements and the store infor- 
mation was changed electronically on command. 
The reference control store was used for input- 
output control and as a link register for storing 
return addresses and subroutine jumps. It also 
used the words it had in storage to modify the ad- 
dresses of other words being operated on in the 
computer. (This step was required in many pro- 
grams in which the address of the next operation 
was based on the results of the previous operation. ) 
A high-speed, ferrite-core, word-organized 
store was developed for this reference memory. 
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Unlike its predecessor, NIKE-ZEUS, and its 
successors, SENTINEL and SAFEGUARD, 
NIKE-X was not a single ABM system concept. 
Rather, it should be thought of as a collective 
term to cover a number of studies and explora- 
tory developments aimed at leading from the 
then outmoded NIKE- ZEUS to the next generation 
ABM system. Figure 2-1 maps the more signi- 
ficant NIKE-X System Studies and supporting 
R&D activities discussed in this chapter. 


NIKE-X began about 1960, when it became 
apparent that by the early 1970s the USSR might 
be able to mount a high-traffic attack against 
the U.S. By 1963 it was accepted that the USSR 
had the technological ability and the expressed 
intention to develop at least a parity in warhead 
yield with the U.S. The sophistication of USSR 
mid-70s ICBM offensive systems was not readily 
predictable; conservative assumptions included 
chaff, decoys, and Electromagnetic Counter- 
measures (ECM) as penetration aids. 


This escalation of the assumed USSR threat 
was a breakpoint in the general approach to the 
NIKE-ZEUS development. Until then the ZEUS 
system had been based on earlier assumptions 
of much lower USSR capabilities. The NIKE- 
ZEUS system had been designed to defend popu- 
lation and industrial centers from a relatively 
light attack. For example, in tracking targets 


Chapter 2. 
NIKE-X SYSTEM 


and missiles, only one target and missile could 
be tracked at one time by the ZEUS Target 
Track Radar (TTR) and Missile Track Radar 
(MTR), respectively. Multiple targets and 
missiles were handled by multiple pairs of 
TTRs and MTRs. Adding single target- 
interceptor tracking subsystems was not a cost- 
effective response to escalation of the predicted 
threats; fundamental changes in radar data- / 
gathering techniques were required. Furthermore, 
the best large-scale computers of the time were 
not capable of handling the data processing loads 
associated with the newly expanded threat con- 
cepts. 


Fortunately, as the threat expanded, - solid- 
state technology evolved enough to make pos- 
sible two important improvements in ABM 
system capability. One of these was the 
development of large electronically steered, 
phased-array radars capable of tracking many 
targets simultaneously. The other was the 
development of high-reliability, very-large- 
throughput data processors for ABM needs. 
The combination of escalating threat and 
expanding technology gave impetus to the_ 
NIKE-X high-traffic ABM concepts. 


The initial thrust of NIKE-X was to develop 
a base of knowledge from which the development 
effort could be started. For example, the 
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MAR-I at White Sands Missile Range (WSMR) ex- 
plored array radar designs to develop a firm tech- 
nical base for NIKE-X. The Reentry Measure- 
ments Program (RMP A and B), in which NIKE-X 
radars observed reentries of IRBMs and ICBMs, 
was another very large, technically challenging 
effort that helped to establish the NIKE-X data 
base. RMP is discussed in detail later in this 
chapter. 


NIKE-X CONCEPT 


The first NIKE-X System Study, in 1963, 
considered a terminal defense for the larger 
U.S. cities against the sophisticated USSR attack 
postulated for the mid-1970s. It was unreason- 
able to make the defense impenetrable; the ob- 
jective was to mitigate damage and thus deprive 
the offense of attractive attack opportunities. 


In developing concepts to meet these city de-— 
fense objectives, several major subsystems 
were defined. The Multifunction Array Radar 
(MAR), which performed search, track, and 
discrimination, was the centerpiece of city 
defense. The Missile Site Radar (MSR) and a 
high-acceleration, atmospheric interceptor, the 
SPRINT, formed a team for fast reaction, high- 
traffic, terminal interception of attacking ICBMs. 
The MAR, MSR, and SPRINT were also respon - 
sible for self-defense of the ABM facilities. 


At the beginning of NIKE-X, a number of 
major elements were carried over from ZEUS: 
the Target Track Radar (TTR), the Missile 
Track Radar (MTR), and the ZEUS missile. 


After the studies of deployment and system 
effectiveness, the defense of cities smaller than 
our 50 largest was studied next. This led to an 
enhanced role for the MSR — the defense of . 
smaller cities. For cost reasons, the MSR, in 
addition to interceptor track and guidance, was 
assigned many roles similar to those of the MAR, 
such as search, track, and target designation. 
Where coverage with the reduced resources of 
the MSR was consistent with the small city re- 
quirements, the autonomous MSR served as a 
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cost-effective duplication, on a lesser scale, 
of the MAR. 


By the mid-1960s, system studies concen- 
trated on reducing the cost of defense and im- 
proving its cost effectiveness. One approach, 
designated TACMAR, was a reduced -power 
variation of the MAR that could, if the need 
arose, grow to full MAR capability. By 1968, 
the city defense concepts were reassessed, and 
the decision was made to shift the defense ob- 
jective to an area defense against relatively 
light attacks. The I-67 Study addressed thisless 
costly area defense objective. With this shift 
in emphasis, ABM moved away from the city 
defense concept, thus removing the requirement 
for MAR/TACMAR. As a result, a much dif- 
ferent kind of sensor was required; one that 
could detect, track, and designate targets above 
the atmosphere at very long ranges. This role 
was first assigned to anew VHF radar, which, 
late in the NIKE-X period, became the UHF 
Perimeter Acquisition Radar (PAR). The in- 
terceptor chosen for area defense was an ex- 
tension of the ZEUS missile, called SPARTAN. 


In summary, the light area defense concept 
was developed through various deployment 
studies, beginning with NIKE-ZEUS, whick was 
a pure area defense system. The ZEUS area 
defense concept was partially incorporated into 
NIKE-X and became a separate concept in the 
Nth Country and I-67 Studies. The chronological 
sequence of area defense studies and postulated 
deployments included NIKE-ZEUS, Nth Country, 
DEPEX, I-67, SENTINEL, and finally 
SAFEGUARD. The other variant, point defense, 
is discussed next. 


DEFENSE OF STRATEGIC FORCES— 
TERMINAL/POINT DEFENSE 


By the mid-1960s, the NIKE-X program had 
two distinct defense objectives: 


1. As discussed above, area defense against 
relatively light threats 


2. Defense of strategic offensive forces 
against high-density, sophisticated 
threats. 

Defense of strategic forces moved toward 
hardened defensive and offensive sites. The ob- 
jective was to present significant, obvious un- 
certainties to the offense planner and hence pro- 
duce influential detefrence. These terminal de- 
fense efforts led to a series of system studies: 
Hardpoint, Hardsite, and VIRADE. An early 
study! of the defense of U.S. strategic forces 
took place in 1963-64. For this study, two con- 
figurations were considered: one for defending 
hardened sites near defended urban areas (called 
HSD-I) and the other for autonomous defense of 
isolated sites (called HSD-II). The study sought 
to protect command and communication facilities 
and the U.S. strategic offensive force, including 
clusters of ICBMs and SAC bases. 


Under joint directorship of the Army and the 
Air Force, a later study? emphasized an active 
defense dedicated to hardened ICBM silos which 
hold the Minuteman strike force. The study 
concentrated on technical tradeoffs between 
parameters in designing the various subsystems 
and drew conclusions about the relative effec- 
tiveness of tactics, deployments, and required 
technology. 


The VIRADE (Virtual Radar Defense) mobile 
system was proposed as a way to increase radar 
attack price by presenting to the attacker a large 
number of possible locations for each available 
system. The proposed system is discussed later 
in this chapter. 


BASIC NIKE-X SYSTEM 
Threat Description 


NIKE-X was designed to counter a high traffic, 
decoyed attack that included active jammers and 
low-visibility Reentry Vehicles (RVs).’ Various 
threats were postulated to guide the design work 
and to serve as models for projecting effective- 
ness. These threat models used USSR ballistic 


missile characteristics, estimated on the basis 
of known technology and intelligence information, 
and were defense conservative. 


The RV was assumed to have low radar 
cross section and high ballistic coefficient.’ 
The USSR would use low cross section, in 
combination with chaff or jammers, to mask 
the exact RV position. Multiple warheads 
were considered likely, and an RV that man- 
euvered evasively in the terminal trajectory 
phase was considered possible. Assumed 
yields ranged from several kilotons to many 
megatons, depending on the mission of the par~ 
ticular RV. Chaff was considered a standard 
countermeasure to obscure the attack outside 
the atmosphere. In addition, "fast chaff'' was 
postulated as a number of simple dipoles, with 
a moderately high ballistic coefficient, serving 
as traffic decoys at high altitudes. More so- 
phisticated decoys would simulate RVs down 
to relatively low altitudes. They would match 
the radar cross section and ballistic coefficient 
of the RV down to an altitude which could force 
the defense to engage them as potentially dan- 
gerous. Active jammers were also assumed 
as penetration aids. 


System Architecture and Operational Concept 
System Elements . 


During its development, which extended 
through 1966, NIKE-X and its defense objectives 
changed several times, which in turn produced 
major changes in configuration. In its original 
form, NIKE-X used two types of phased-array 
radars (MAR and MSR), two defensive missiles 
(SPRINT and ZEUS), and a modular, multi- 
processor data processing system. In addition, 
the NIKE-ZEUS Target Tracking Radar and 
Missile Tracking Radar remained parts of 
NIKE -X until it was verified that the phased- 
array MAR had the accuracy needed for long- 
range intercepts. 7 


The L-band MAR was to be installed in dense- 
ly populated urban/industrial areas (see artist's 
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view of city defense in Figure 2-2) for (1) the 
long-range search needed for attack recognition 
and (2) the quick reaction, high-traffic capability 
needed for terminal defense. Associated with 
each MAR was a Defense Center Data Processing 
System (DCDPS) which controlled the MAR and 
any MSRs in the same area. With the MAR as 
its principal sensor, the DCDPS performed all 
urban defense functions: detecting, tracking, 


and evaluating threats, planning the battle, and 
guiding defensive missiles. 


For terminal defense, NIKE-X relied on 
SPRINT, a relatively small, high-acceleration 
missile, which is described more fully in Chap- 
ter 9. SPRINT is aerodynamically guided (ex- 
cept for first-stage boost) and designed for. 
intercepts within the atmosphere. Its warhead 





Figure 2-2, City Defense 
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has maximum lethality at its operational alti- 
tudes. For terminal defense of a large area, 
SPRINT missile farms were emplaced at various 
points about the defended urban center, parti- 
cularly forward of the MAR. 


The S-band MSR originally had two functions: 
missile tracking and target tracking at relatively 
short ranges. A missile tracker was needed 
at the forward SPRINT farms because the MAR 
would generally not have a line-of-sight to the 
SPRINTs at launch. The MSR could launch and 
guide the SPRINT to intercept, or launch and 
then transfer control to the MAR when the 
SPRINT came into the MAR's view. The MSR 
could track targets at relatively short range and 
look behind nuclear fireballs that obscured MAR 
coverage. Also, it could either look behind or 
permit triangulation on jammers, and generate 
additional tracks when required by traffic levels. 


By mid-1964, a Small City Defense (SCD) 
concept was firmly established as part of NIKE- 
X. In this concept, the MSR role was expanded 
so that it was deployed either singly or in 
groups to provide a somewhat autonomous de- 
fense of small urban areas. The SCD also had 
a smaller version of the DCDPS, called a Local 
Data Processor (LDP). In addition to the target 
and missile tracking functions originally assigned 
to the MSR, the MSR-LDP combination carried 
on search, verification, and limited threat 
evaluation. 


The ZEUS missile was included in NIKE-X 
whenever intercepts were required at extended 
ranges and high altitude. It was a somewhat 
modified version of the standard missile de- 
veloped for NIKE-ZEUS. Although it was con-. 
ceived that NIKE-X would defend concentrated 
urban areas and rely on close-in use of the 
SPRINT missile, several uses were envisioned 
for the ZEUS missile. Its exoatmospheric 
capability could "break up" a heavily cluttered 
attack, particularly if salvos of ZEUS missiles 
were launched. For attacks simpler than those 
expected against urban centers, such as 
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submarine-launched missiles aimed at suburban 
or peripheral targets, the ZEUS missile could 
extend the effective coverage of a NIKE-X in- 
stallation. Other potential uses for the ZEUS 
missile included intercept of a three-quadrant 
ballistic missile approaching from the south and 
intercept of low altitude satellites. 


Operational Concept 


NIKE-X was designed as a defense against 
a massive, sophisticated ballistic missile 
attack. All phases of the defense, from sur- 
veillance to missile guidance, were controlled 
by stored programs in the DCDPSs and LDPs. 
Man's role in the defense was regarded as one 
of augmenting and modifying system responses, 
once he had released the defending missiles. 
Although advantage would be taken of any attack 
that was simpler than expected (e.g., without 
decoys or chaff), the operational concept en- 
visioned the decoyed, chaff-obscured attack, 
possibly also masked by active jammers. 


The system's radars — the MAR supple- 
mented by the MSR — would perform constant 
surveillance against attack from any direction, 
with emphasis on expected attack corridors. 
MAR would detect the large, chaff-obscured 
threat complexes, or "clouds, '' as they ap- 
peared above the radar horizon and start to 
track them. Depending on attack geometry, a 
track could be an individual object or a whole 
threat cloud. 


Engagement planning would begin as soon as 
a threatening target was detected. The first 
action would be to determine the feasibility 
of launching ZEUS missiles. They would be 
launched to disperse chaff, disable jammers, 


disorganize or destroy decoys, and kill warheads. 


Any information from adjacent MARs with a 
side look at the threat cloud-would facilitate 
ZEUS engagement planning. The next step 
would be to plan the SPRINT response. As the 
threat cloud entered the atmosphere, a "threat 
tube"’ would be defined. This tube would have a 
circular or elliptical cross section and define 


the envelope formed by the reentry trajectories 
of threatening objects in the cloud. 


MAR used a "monosweep" technique to scan 
threat tubes and track each object separated 
from the chaff background by atmospheric inter- 
actions. In monosweep, a cluster of MAR re- 
ceiver beams was simultaneously steered in 
angle and controlled in beamwidth so that the 
threat tube was "swept" for signal returns after 
each radar transmission. This technique, 
which used the flexibility of the Modulation Scan 
Array Radar (MOSAR) beamforming and steering 
method, produced receiver beam clusters whose 
width just matched the threat tube width at each 
range that yielded a radar return. The signal 
strength of objects in the threat tube was thus 
maximized at any given range. 


As the reentering objects in the threat tube 
were resolved, their radar signals would be 
processed to estimate their weights and ballis- 
tic coefficients. SPRINT missiles would be 
launched to intercept threatening objects as 
they were identified. , 


Deployment 


The NIKE-X system was modular, and the 
primary purpose of each module was to defend 
a single urban area. Defense components would 
be allocated to limit fatalities during those 
attacks designed to inflict maximum fatalities. 
Secondary deployments included locating the 
MARs to defend small cities and adjacent MAR 
modules. 


Specific deployments analyzed during the 
NIKE-X development ranged from covering a 
relatively small number of cities, including no 
Small City Defense (SCD) modules, to furnish- 
ing essentially total city coverage, including a 
large number of SCD modules of various types. 
Each deployment could be implemented in 
phases to achieve the highest level of overall 
defense at any point in time. 
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Functional Capabilities of Major Subsystems 


This paragraph briefly describes each major 
subsystem, emphasizing its role and relation- 
ship with the whole.° 


Multifunction Array Radar (MAR) 


MAR was an L-band, high-power, phased- 
array radar that was NIKE-X's principal sensor. 
It had four functions: (1) search and verification, 
(2) threat evaluation, (3) target track, and 
(4) missile track. Its multifunction capability 
was achieved through electronic beamforming 
and steering controlled by programmed data 
processing equipment. 


The MAR had separate transmitting and 
receiving subsystems, with two transmitting 
and two receiving arrays per radar. Each set 
of one transmitting and one receiving array 
was effective over one quadrant of the radar's 
combined 180-degree azimuthal coverage. 
Each array consisted of a large number of 
cylindrical elements whose radiating ends 
formed a planar face approximately circular 
in shape. 


The MAR could transmit signals of any of 
14 different waveforms for its several functions. 
These waveforms varied from single CW pulses 
of 1 to 440 microseconds length to chirped 
pulses and pulse trains. The pulse trains were 
used for discrimination, with the most sophisti- 
cated being a sequence of 32 coherent 6.2-micro- 
second pulses, 12.4-microseconds apart with a 
30-megahertz bandwidth. With its long search 
pulse, the MAR could detect small objects in a 
reentry complex as they crossed the radar hori- 
zon. 


The MAR receiver used a technique of elec- : 
tronic beamforming and steering Inown as 
"modulation-scan"' or MOSAR, which was de- 
scribed under Operational Concept above. 


Missile Site Radar (MSR) z 
The MSR was an S-band, single beam, phased- 


array radar that, depending upon its defensive 
role, could be built with one to four phased-array 








Figure 2-3. SPRINT Missile Firing 


lens-type antenna faces. In all configurations, 
a single transmitter and receiver time-shared 
the face(s). The MSR could transmit or receive 
in one direction at a time as opposed to MAR's 
multifunction operation. The four-faced MSR 
provided 360-degree azimuthal coverage. 


The MSR had four system functions: (1) search 
and verification, (2) target track, (3) limited 
threat evaluation, and (4) missile track. In the 
plan for Small City Defense, the MSR, along with 
its associated data processor, performed all four 
of these functions. When it was deployed as part 
of the MAR defense module, its role would be 
primarily that of target and missile tracking. 
The MSR could transmit any of six different 
waveforms, including short and long CW pulses, 
a chirped pulse, and a pair of pulses for threat 
evaluation. 
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SPRINT Missile 


SPRINT was a two-stage, solid propellant 
missile designed for short-range intercepts 
inside the atmosphere. (See Figure 2-3.) It 
was intended to be guided by radio command 
guidance from either the MAR or MSR, but only 
the MSR guidance transponder was developed. 
Its first-stage flight was controlled in pitch and 
yaw by a thrust vectoring system in which liquid 
Freon* was injected into the booster exhaust. 
During second-stage flight the missile was 
steered by aerodynamic forces acting on air 
vanes. A pulsed transmitter in the missile 
served as an S-band or L-band beacon, depending 
on the ground radar. = 


*Trademark of E. I. DuPont de Nemours. 


* 33 
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The SPRINT missile was ejected vertically 
from an underground launch station by a gas- 
powered piston. After it cleared the launch 
cell, its first-stage motor was ignited; the 
second-stage motor was ignited after the first 
stage burned out. SPRINT was ahigh-accelera- 
tion, highly maneuverable missile that could 
intercept targets between 5 and 100 kilofeet 
high. A typical intercept would occur at an 
altitude of 40,000 feet, ata ground range of 
10 nautical miles, after about 10 seconds of 
flight time. See Chapter 9 for a more complete 
description of this missile. 


ZEUS Missile 


ZEUS was a three-stage, solid propellant 
missile designed for long-range intercepts with 
radio command guidance from either the MAR 
or MSR. (See Figure 2-4.) In the atmosphere, 
aerodynamic forces acting on the third-stage 
control fins controlled steering. Outside the 
atmosphere, gases expelled through the same 
fins controlled motion. A pulsed transmitter 
in the missile was beacon tracked by the ground 
radar. 


The ZEUS missile, launched from an under- 
ground station at an angle of 85 degrees from hori- 
zontal, was unguided until second-stage ignition. 
The first and second stages had similar character- 
istics and accelerated the third stage to peak 
velocity. The third stage carried the warhead, 
missile guidance set, autopilot, fin servo sys- 
tem, hydraulic system, and the thrust vector 
motor. See Chapter 1 for a more complete de- 
scription of ZEUS, and Chapter 10 for a descrip- 
tion of SPARTAN, the successor to the ZEUS 
missile. 


A typical ZEUS missile intercept, which would 
take place 100 nautical miles above the tangent 
plane at a tangent range of about 300 nautical 
miles, would require a flight time of about 300 
seconds. For such an intercept, aerodynamic 
steering would remove trajectory errors before 
the missile left the atmosphere. The missile 
would then "coast" without guidance or thrust 
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Figure 2-4, ZEUS Missile Firing 


until third-stage ignition. Controlling the third 
stage by thrust vector reaction would remove 
residual trajectory errors just before intercept. 
For longer range intercepts, the third-stage 
motor could be ignited earlier and used to in- 
crease missile range at the expense of accuracy. 


Data Processor 


There were two general forms of data proc- 
essor in NIKE-X: the Defense Center Data 
Processor (DCDP) and the Local Data Processor 
(LDP). The difference between them was in the 
number of modules (processors, stores, dis- 
play consoles, etc.) each contained. Because 
of its modular design, the data processor could 
be sized for its particular application at each 
site. Within each DCDP and LDP, the general 


purpose Central Logic and Control (CLC) per- 

formed the computation and central processing. 
Manual command and control was implemented 
by the Display Subsystem (DSS). 


Automatic control was centered in the CLC. 
Computer programs, stored in program stores, 
controlled NIKE-X system operations as inter- 
preted and executed by processor units. The 
processor units obtained input data from variable 
stores and stored computation results there. 
Processor units operated in parallel, forming a 
multiprocessor system in which each processor, 
as it became idle, was assigned a computational 
task, or program segment, to execute. 


The DCDP used separate report processors 
for routine initial data processing of MAR radar 
returns. This wired logic preprocessing 
relieved the CLC of many repetitive computa- 
tions on a large amount of data. 


Nth COUNTRY DEFENSE STUDIES 


Basic to the NIKE-X concept, as it developed 
during 1963 and 1964, was the idea of defending 
industrial and suburban centers against heavy 
USSR attacks during the 1970s.4 The objective 
was to minimize overall damage to the country. 


The cost of limiting damage against massive 
and sophisticated attacks was relatively high, 
and only part of the population was protected. 
From early 1965 to late 1967, increasing 
interest in potential "Nth Country" or "light" 
attacks,® as well as developments in nuclear 
warhead technology, * led to a series of studies 
and deployment options. The Nth Country or 
area defense concept evolved from those 
studies as a defense against light attacks, along 
with concepts of terminal defense,’ including 
defense of strategic forces. This effort cul- 
minated in the NIKE-X I-67 deployment con- 
cept,’ the harbinger of the SENTINEL System. 





*Applicable to ZEUS or modified ZEUS missiles. 
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During this time, there were significant 
changes in equipment concepts: the PAR was 
conceived and its development commenced, the 
autonomous MSR came into being, and the 
ZEUS DM-15C missile was extensively modified 
to eventually become the SPARTAN missile. 


Defense Objectives ee 


The evolution of NIKE-X was naturally 
shaped by the evolution of defense objectives, 
which were in turn shaped by prevailing econ- 
omic, political, and technological factors. 
Initially, the objective was to blanket the Conti- 
nental United States (CONUS) with a high- 
altitude ZEUS-type defense, backed up at urban 
centers by a close-in SPRINT defense. 


By the time of the I-67 deployment study, 
defense objectives had crystallized into two 
major roles, with some equipment elements 
supporting both: 

1. By minimizing the probability of pene- 
tration, the defense was to deny damage 
in relatively light attacks. As the attack 
force grew, the defense was to minimize 
population fatalities. Also, modularity 
allowed growth from the original deploy- 
ments against light attacks to a damage- 
limiting defense against highly sophisti- 
cated threats from any source. 


2. The defense was to ensure that a sig- 
nificant number of the Minuteman 
strategic missile force would survive a 
USSR attack. 


Threat Description 


An Nth Country, lacking an extensive indus- 
trial base, could only attack the U.S. witha 
limited number of relatively unsophisticated 
ICBMs and SLBMs. It was assumed that this 
limitation would remain quite stable, with the 
significant variants being the offensive force 
level, RV vulnerability, and the number of 
SLBMs. : 


The NIKE-X I-67 Study assumed that up 
through 1980 the Chinese Peoples’ Republic 
(CPR) threat would simply be a single large, 
blunt warhead accompanied by a tank and hard- 


ware pieces. Both the warhead and the tank had 


large radar cross sections, since no attempt 
was made to conceal either. After 1980, the 
CPR RVs would grow moderately in sophistica- 
tion and significantly in numbers. 


Although the later NIKE-X developments 
basically considered that the USSR threat would 
be directed against Minuteman forces, NIKE-X 
nonetheless was a factor in area defense because 
it had to defend the country against accidental 
launches of USSR ICBMs. The postulated USSR 
threat, although more sophisticated than the 
early threat, determined the eventual NIKE-X 
response with long-range interceptors. 


Operational Concepts 


At the beginning of this development period, 
it was considered that the modified ZEUS missile 
‘would support the terminal defense of industrial 
and urban centers. ZEUS missiles would dis- 
rupt "penetration aids" decoys, chaff, etc.) and 
allow the MAR to gather data on RVs as early as 
possible. 


By the mid-1960s, the emphasis was to re- 
duce the cost of defense, so new directions for 
NIKE-X were evolving. At the same time, de- 
velopments in warhead technology altered the 
earlier concepts about the modified ZEUS and 
gave it a significant capability for killing RV/ 
warheads during attacks that included penetration 
aids. By this time the possibility of light attacks 
was being considered, although concern about 
sophisticated attacks remained dominant. 


These changes in emphasis eventually led to 
a less powerful MAR, designated TACMAR, 
which could search for and track the basic 
NIKE-X threats at long ranges. It could react 
early enough for modified ZEUS to intercept 
threats and protect almost all of CONUS from 
the unsophisticated threats. Around urban cen- 
ters ZEUS would be backed by SPRINT, which 
gave the cities two levels of defense. Because 
Nth Country threats involved moderate to small 
RVs without penetration aids, a VHF radar was 
required for long-range detection of these at- 
tackers, thus complementing the TACMAR. 
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In addition, to defend the U.S. against at- 
tacks from any direction and for terminal de- 
fense, the proposed typical NIKE-X deployments 
consisted of TACMARs, VHF radars, and 
ZEUS/SPRINT/MSR sites. (The MTR-TTR 
combination of ZEUS intercept was no longer 
required. )? A * of: Se 


Next, further evaluation of these basic ideas 
led to the NIKE-X Deployment Study (DEPEX), 
which organized the defense against attack from 
an Nth Country and light attacks from the Soviet 
Union.’ The basic objective was still to protect 
population and industrial centers. Particular 
attention was given to countering the ballistic 
missiles the CPR might eventually develop. 

The defensive deployment was to grow so it 
could meet the more massive and sophisticated 
ballistic missile threats arriving from any 
quarter. The DEPEX concept by and large re- 
tained the basic characteristics described 
above, and added a four-phase deployment 
sequence. The first phase was about as de- 
scribed in the above deployment options, but 
more extensive, while in the next three phases 
the terminal defenses grew in steps. 


Increasing interest in very light deployments, 
at least during the initial stage of deployment, 
led to the DEPEX "Phase 0,"* which, for the 
most part, used modified ZEUS missiles, VHF 
radars, MSRs, and a few SPRINTs.’ In addition 
system Studies showed that somewhat higher 
frequencies for the long-range search radars 
would strike the most cost-effective balance 
between susceptibility to nuclear effects and the 
long-range detection and track of objects with 
small radar cross sections. Concurrently, 
interest in defending the Strategic Offensive 
Forces became stronger. 


, 


This concept embodied the objective of deny- 
ing damage to an early CPR attack.and provided 
a moderate high-level terminal defense for 
Minuteman forces.’ It also allowed for growth 
to heavy terminal defense. 


By this time, the needed long-range charac- 
teristics were embodied in a new UHF radar 
called PAR. - The design of the modified ZEUS 
was stabilized and the missile was renamed 
SPARTAN. 


The I-67 deployment used a few PARs, mod- 
erate numbers of MSRs, and many SPARTANS 
and SPRINTs. The MSR and SPRINT missile 
system defended the Minuteman bases and were 
also collocated with each PAR site. The re- 
maining MSRs and SPARTANS were strategic- 
ally located throughout CONUS. 


In this system, PARs carried out long-range 
surveillance and target tracking. In area de- 
fense, SPARTAN served as the primary inter- 
ceptor, tracked and guided by the MSR. SPRINTs 
were to be used only to defend PARs, urban 
areas near the PARs, and Minuteman silos. 


Generally, targets would be detected first by 
the PARs. After they were tracked for some 
seconds, their trajectories and impact points 
would be determined and the defense battery 
would be designated. In SPARTAN engagements, 
information on target intercept would be con- 
tinually refined and passed to the Missile De- 
fense Center battery assigned the engagement. 
This battery would launch and guide interceptors 
to the appropriate point. The concept was a good 
cost-effective balance between radars (PAR), 
radar resources (tracking requirements), and 
lethal effects from the large-yield SPARTAN 
warhead. 


I-67 deployment concepts represented the 
first real effort to set up a nationwide ABM 
command and control system and set forth the 
functional logic of a defensive engagement. The 
PAR would operate somewhat independently, 
with built-in rules governing normal search 
assignment, detection, verification, and track 
initialization. The MSR was more closely 
coordinated (between MSRs) within a Missile 
Defense Center region. In fact, one facet of 
NIKE~X at this point was the increasing degree 
of intersite netting that furnished CONUS-wide 
coverage with a few search radars. 
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With minor modifications, the I-67 deploy- 
ment and its operating concept led directly to 
SENTINEL and later to SAFEGUARD, as dis- 
cussed in Chapters 3 and 4, respectively. Many 
SAFEGUARD features and characteristics had 
their origin in the I-67 deployment concept of 
NIKE-X, which marked a fundamental milestone 
in the evolution of SAFEGUARD. 


Modified SPARTAN 


Between 1968 and 1971, there were exten- 
sive studies of improving the SPARTAN inter- 
ceptor in its assigned role and in a role against 
more sophisticated attacks.!" This effort is men- 
tioned here because it falls into the studies 
associated with area defense. 


The study explored the utility of a high- 
performance (higher than SPARTAN), long- 
range, exo- and endoatmospheric interceptor 
that would significantly reduce the number of 
MSR/ missile sites required to defend CONUS. 
New tactics and advanced intercept concepts 
were also studied. However, cost-effective- 
ness considerations terminated the effort in 
1971. 


DEFENSE OF STRATEGIC FORCES— 
TERMINAL HARDSITE DEFENSE 

Between 1963 and 1969, Bell Laboratories postu- 
lated several systems for defending hardened U.S. 
ICBM sites. The systems evolved in response 
to specifications of the threat and trial deploy- 
ments, and they were examined from the stand- 
point of cost, component availability, and effec- 
tiveness in achieving objectives. 


The primary objective of hardsite defense 
was to deter enemy attacks on the U.S. stra- 
tegic ICBM offensive force. If deterrence 
failed, the defense was to save enough Minute- 
man boosters that the U.S. could carry out 
its post-attack policy. The defense was to be 
effective against an advanced-technology threat 
including penetration aids. Existing technology 





and components were to be used in the proposed 
deployments as fully as possible. 


One of the first two hardsite systems proposed 
was designed to protect sites in urban areas;! 
the other to defend sites at remote locations. A 
hardened site could be a command and communi- 
cation facility at a SAC base or a cluster of 
ICBM silos. In a later study, only hardened 
silos having the Titan It and Minuteman forces 
and the hardened defense elements were to be 
defended.? In this work other contractors’ 
schemes were also reviewed. They ranged from 
area/terminal defenses similar to the Bell 
Laboratories concept to proposals for the autono- 
mous defense of each silo (called "hardpoint" 
defense). 


The last major Bell Laboratories study of 
hardsite systems resulted in the proposed 
movable radar, or Virtual Radar Defense 
(VIRADE) system, which furnished extended 
terminal coverage through radar netting! In 
this approach, the radar antenna and transmit- 
ter would be transported by rail and moved 
frequently among a large number of hardened 
radar sites. VIRADE was an alternative to 
fixed radars and was intended to increase the 
radar attack price. It recognized the practical 
limits and cost of increasing radar hardness, 
introducing redundancy, or using decoy radars 
to force the attacker to increase the “throw - 
weight" of his offensive missiles. 


Each hardsite study indicated that MSR 
technology would be adequate, and each study 
increased the radar hardness levels. Early in 
these studies it was recognized that both data 
processing and hardsite requirements for radar 
netting and resource allocation would be com- 
plex. Computers would have to use faster 
circuitry and different organizational schemes 
to achieve the required throughput. The inter- 
ceptor proposed for each system was the 
SPRINT. Interceptors with improved perform- 
ance would counter a more sophisticated at~- 
tacking vehicle, which could maneuver to 


2-13 


increase its chances of penetrating the NIKE-X 
defenses .!2 


The defense system design took into account 
uncertainties faced by the attacker. These 
uncertainties were caused by the disturbed 
environment created by his warhead bursts, 
target vulnerability, and the presence of an 
active defense. Defense parameters that 
affected system requirements included sure- 
safe and sure-kill hardness levels for radars 
and silos, single-shot warhead kill probabili- 
ties, peak traffic rates, and the attacker's 
targeting doctrine. From these considerations 
and knowledge of the Soviet ICBM force, a 
threat was specified. The ICBM force was 
sized, assumptions were made about Multiple 
Independently Targeted RVs (MIRVs), only 
high weight-to-drag RVs.were included, and 
trajectory geometries were bounded. The 
attacker's payload was estimated, his booster 
availability, reliability was computed, and his 
warhead yield and vulnerability to interceptor 
bursts were estimated. 


The threat was enhanced by penetration aids 
which included tank fragments, precursor 
bursts, chaff clouds, traffic decoys, ECM, 
and maneuvering RVs. Many possible ways 
to distinguish warheads from penetration aids 
were considered, and many were found un- 
suitable 3 


PARALLEL ELEMENT PROCESSING 
ENSEMBLE 


As studies of ballistic missile defense sys- 
tems progressed, the postulated threats ex- 


panded greatly in terms of the number of objects 


arriving simultaneously and the sophistication 
of the penetration aids. This increase in threat 
influenced ABM design and especially increased 
the estimate of throughput needed for ABM data 
processors. . 


In response, a new concept of architecture 
for the ABM data processor was suggested.'! 


Because a large part of the processing asso- 
ciated with radar tracking and discrimination 
required that the same set of algorithms be 
repeatedly applied to each object, parallel 
elements might carry on the processing. In 
1964, research began on a content -addressable 
memory invented by Lee and Paull of Bell 
Laboratories. This memory offered an approach 
to the needed parallel processing, and a follow- 
on development program supported by the 
Advanced Ballistic Missile Defense Agency 
(ABMDA) led to the Parallel Element Processing 
Ensemble (PEPE) concept. 


PEPE was a programmable, special-purpose 
computing machine that augmented conventional 
sequential computing in ABM data processing. 
Processing capacity was largely independent 
of traffic because an independent parallel ele- 
ment was assigned to each object in track. 

Each parallel element was, in fact, a small digital 
computer, with an arithmetic unit and memory. 

In addition, each contained a special-purpose 
input unit called a "correlator, '' which associated 
radar replies with the appropriate track by simul- 
taneously comparing each radar reply with pre- 
dicted track positions. Most of the control cir- 
cuitry was in an ensemble control unit, which 

was connected in turn to a more conventional 
“host" sequential digital computer. The host 
computer stored instructions for the parallel en- 
semble, sequenced through them, and passed 
them to the ensemble control unit. The host com- 
puter also did the processing that could be most 
effeciently handled by a sequential computer 5 


By the mid-1960s, a study was under way to 
adapt PEPE to ABM. The intent was to realis- 
tically assess feasibility and cost factors. 
Several studies were launched, primarily in 
the areas of software development and testing. 


Hardware Feasibility 


Using readily available components, a proc- 
essor with 16 elements was built with integrated 
circuits and tested with an IBM 360/65 as a 


host computer. This "IC Model" of PEPE was 
used in the demonstration tests discussed 
below. A study which showed the feasibility 
of using more advanced large-scale integrated 
circuits in PEPE was completed toward the 
end of the development project. 


Software Development 


Since the job to be done by parallel process- 
ing elements would be done the same way by a 
sequential computer, similar programming 
methods could be used. A parallel version of 
FORTRAN, P-FOR, became PEPE's basic 
programming language. P-FOR was supported 
by a compiler and an assembler to convert 
programs into machine code. Also, programs 
could be written for input to the assembler 
using PAL, the Parallel Assembly Language. 


The language and software system were avail- 
able well before any hardware so that programs 
could be tested by simulation. The P44 pre- 
compiler converted each operation on parallel 
data in a P-FOR program into a DO loop on an 
array in a standard FORTRAN program. The 
FORTRAN program could be readily tested on 
any machine with FORTRAN capability. 


In addition to P44, which tested P-FOR 
programs at the source level, the Parallel 
ABM System Simulation (PASS) simulated 
operation at the machine level. PASS Tests I 
to IV, each testing a broader system, were 
planned. PASS I and IE demonstrated PEPE's 
capability for basic ABM processing and were 
completed. PASS III and IV were replaced by 
tests defined by ABMDA, as noted below. 


Application Studies 


To identify problems and evaluate the advan- 
tages of PEPE, several specific applications 
were studied: "” 

e SAFEGUARD. Routines planned for 

SAFEGUARD as developed in NIKE-X 


simulations were converted to parallel 
form in PASS I and II.8 


ee 


eee Saye 


e VIRADE. As discussed previously under 
Defense of Strategic Forces, the 
VIRADE concept added the problems of 
changing sites to the basic ABM prob- 
lems. 


e ABMDA defined tests. For a final evalua- 
tion of PEPE as part of the Bell Labora- 
tories development program, ABMDA 
defined two systems: Zero Order Software 
{Z08) and Preliminary Hardsite Defense 

PHSD). These replaced PASS III and IV. 
The final PHSD demonstration was against 
a threat defined by General Research 
Corporation and transmitted to Bell 
Laboratories by data link from Santa 
Barbara, California in interrupted real 
time. The PEPE system used in this test 
was the 16-element IC model supplemented 
by sequential simulation, and it achieved 
essentially all the test objectives.2° 


Lessons Learned 


e The ability of PEPE to carry a large, 
constantly growing portion of SAFEGUARD 
data processing was established. The 
threat level defined for the current 
SAFEGUARD System did not make PEPE 
cost effective. Its cost effectiveness would 
have to be established for a given threat, 
for a given ABM system, and with the 
current state of the processor art con- 
sidered. 


e The feasibility of increasing system capa- 
bility by removing processing from a 
sequential computer and assigning it toa 
parallel processor was established. 


e The high level language, P-FOR, was found 
to be a powerful tool in rapidly program- 
ming a complex system. 


REENTRY MEASUREMENTS PROGRAMS 
A, B, AND C 

The NIKE-X Reentry Measurements Pro- 
gram (RMP), which spanned the interval from 
1960 to 1970, had the objective of developing 
discriminants for conical RVs. The program 
used a straightforward phenomenological ap- 
proach, with tabulated comparisons of radar 
observable characteristics as functions of 
vehicle size, shape, and ablator material. 


To complete the program, a broad spectrum 
of targets was observed by the radar, optical, 
and infraredsensors”! at the Eastern Test Range 
(ETR), Kwajalein Test Site (KTS),“4 and White 
Sands Missile Range (WSMR).” Most of the 
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RMP flights were full-scale reentry tests 
flown into the Kwajalein Test Range. The 
NIKE -X program supplied many of the unique 
targets. Other targets came from the Air 
Force Advanced Ballistic Reentry Systems 
(ABRES) Studies, SAC Evaluation Missions, 
and the Navy Polaris Program. so 


The RMP general test requirements were 
coordinated through the Tri-Agency Technical 
Coordination and Operations Group (TATCOG), 
an Army, Navy, and Air Force committee that 
set test objectives and planned coordination. 
The responsibilities and contributions of the 
various RMP groups were divided as follows: 


1. Bell Laboratories. Specified program 
objectives, reentry hardware perform- 
ance requirements,. and target delivery 
(trajectory and deployment) requirements. 
Operated the NIKE radar sensors and 
EC121 optical aircraft. Reduced and 
analyzed collected data. 


2. Army. Procured target vehicles and 
delivery systems through the Air Force. 
Coordinated test requirements, program 
objectives, and schedules. Provided the 
Kwajalein Test Range support. Coor- 
dinated interservice data exchanges. 


3. Air Force. Provided the reentry hard- 
ware, booster systems, and the ETR 
facilities; i.e., delivered targets to KTS. 
Exchanged technical data and coordinated 
their reentry study program, ABRES, to 
support mutual~interest missions. 


4. Navy. Cooperated in providing SLBM tar- 
gets. Coordinated mission planning and 
data exchange. 


5. Lincoln Laboratory. Supplied technical 
consultation and coordinated design of 
reentry experiments and data analysis 
exchange. ati additional sensors 
(data sources) of the PRESS facilities at 


Test Objectives 


The RMP was divided into several significant 
phases. Initially, from 1960 to 1964, the 
NIKE-X Field Measurement Program (FMP)*:25.26 
developed sensor techniques and discrimination 
technology. The prime objectives developed 
then, which were changed very little in the 
follow-on RMP, were to determine: 


@ The observables associated with various 
targets, which would define the sensor 
techniques for obtaining adequate dis- 
crimination measurements 


@ The relationship between various target 
types and sensor measurements to define 
effective discrimination techniques.?! 

From approximately 1964 through 1966, the 
experiments labeled"-RMP-A??*"* were con- 
cerned with the class of material used in RVs.”2?3 
The primary objective was to search for and 
evaluate discriminants. 29 


The RMP-B program (1966-1970) **> sought 
to establish basic theoretical understanding of 
reentry phenomena so that experimental meas- 
urements and discrimination techniques could be 
extrapolated to other possible threat sizes and 
variations.3¢-32 Another area of RMP-B was the 
qualitative confirmation, through on-board in- 
strumentation,? of basic reentry phenomena 
that could not be measured from the ground. 


RMP-C was to consider advanced RVs. 
Before the target requirements were specified, 
the program was terminated about 1970. 


Target Vehicle Summary 


The RMP used a series of reentry measure- 
ments vehicles, tactical offensive weapons with 
penetration aids, and vehicles developed for 
future offensive weapons. The Reentry Meas- 
urements Vehicles (RMVs) were uniquely 
developed for the RMP. 


Missions and Data Reports 


Bell Laboratories issued a Target Measure- 
ments Report (TMR) on each reentry measure- 
ment mission. These documents briefly sum- 
marized the operation and outlined pertinent 
factual information. Data available for con- 
tinued analysis were listed, and plots, photo- 
graphs, and available reentry identification 
information were included. The TMR data 
reports are available at the Reentry Data 
Facility at Calspan Corporation, Buffalo, N. Y., 
a data repository maintained by the Army. 


MULTIFUNCTION ARRAY RADARS 
The MAR-I Program 


In the early stages of NIKE-X, 1963-1964, 
the Multifunction Array Radar (MAR) was 
foremost among the relatively new radar con- 
cepts. This radar was to be the major NIKE-X 
sensor, able to perform in many operational 
modes in a high-traffic environment and to 
carry out endo- and exoatmospheric engage- 
ments. The MAR's principal task was to form 
and steer the multibeam clusters that would 
perform the radar missions of search, track, 
discrimination, and guidance. 


By that time, studies of phased array radars 
had progressed to the point where the funda- 
mentals of their antennas and beamforming 
were well understood. A number of arrays 
had been built to demonstrate some of their 
basic capabilities. Prior to MAR, however, 
these sensors had been designed for a single 
function, principally that of target acquisition 
and tracking. 


By 1963 the NIKE-X program had reaped 
substantial benefits from two experimental: 
linear arrays, one employing the time delay 
steering proposed by Sylvania, the other using 
a novel modulation scanning technique developed 
by the General Electric Company. Early tests 
of these two arrays formed a technical base 
from which a complete array radar feasibility 
effort was launched. This radar complex was 
identified as MAR-I. The design, construction, 
installation, and testing of MAR-I took place 
in the 1961-65 time period. A close-up view 
of the installation at WSMR is shown in 
Figure 2-5. ; 


Development tests of the radar, scheduled 
into 1965, determined how well the equipment 
met design objectives and furnished data for 
design improvements to the NIKE -X tactical 
model (MAR-II) planned for installation at 
Kwajalein. The development program included 


extensive antenna pattern measurements and 


beam stability checks to evaluate the 
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Figure 2-5, Close-up View of MAR-| at White Sands Missile Range 


beamforming and steering concepts. Dynamic 
tracking accuracy and multiple beam operation 
tests were also included. 


Major contractors and their responsibilities 


were: 
1. Western Electric. Acted as prime con- 

tractor for the MAR-I project under 

contract DA-30-069-AMC-333(Y). 


2. Bell Laboratories. Held overall responsi- 
bility for project management, including 
design, development, building construc- 
tion, test site operation, and system 
evaluation. 


Sylvania Electronic Systems, East 
Waltham, Mass. Developed a multifunc- 
tion array radar by designing, construct- . 
ing, installing, and testing MAR-I 
electronic equipment. 


Sperry Rand Univac, St. Paul, Minn. 
Designed the MAR-I Phase II digital 
computer, the associated Control Switch 
and Buffer (CSB), and the computer 
programming. 


Western Electric and Bell Laboratories also 
designed and constructed some of the MAR-I 
equipment. 
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Functional Capabilities 


The MAR-I at White Sands was designed to 
perform the functions shown in Figure 2-6 and 
to demonstrate fully automatic operation.* 
Manual override and a full manual capability 
were included to allow flexibility in testing. A 
tactical system would operate in two modes: 
surveillance (the normal mode) and engagement 
(which began after a target had been detected 
and classified as a threat to the defended area). 
The automatic elimination of targets as non- 
threatening, based on impact predictions or 
discrimination, was never implemented in this 
radar. 


In the surveillance mode, the system per- 
formed two functions: search (and detection) 
and verification tracking. In the engagement 
mode, the system performed four functions: 
search (and detection), verification tracking, 
precision tracking, and discrimination sensing. 
Except when restricted by the operator, MAR-I 
automatically carried out verification tracking 
assignments on all targets detected in the search 
beam. 





2 WHEN A THREAT {iS VERIFIED, 
A CHANGE IS MADE FROM 
SURVEILLANCE TO ENGAGE— 
MENT MODE. 








DEFENDED AREA 


Figure 2-6. MAR Functional Capabilities 
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After verification, a precision tracker was 
assigned to threats and used the target position 
estimates generated by the verification tracker. 
Except for a coded pulse that increased range 
resolution, precision tracking was essentially 
the same as verification tracking. A sub-beam 
cluster, positioned either automatically or 
manually to cover a threat tube, obtained dis- 
crimination data. Threat tubes were cylindrical 
volumes whose axes were parallel to the veloc- 
ity vector of the target. A Coherent Signal 
Processing System (CSPS) for acquiring discrim- 
ination data was developed but never installed 
in MAR-I. It was added to the Discrimination 
Radar (DR) at Kwajalein to support the Reentry 
Measurements Program (RMP). 


System Description 
Operational Concept 


MAR-I operations reflected the two modes, 
surveillance and engagement, in which a tactical 
system would function.® In the surveillance 
mode, the radar beam scanned the total cover- 
age volume in less than 20 seconds. Whena 
target was detected, the radar returns were 
examined automatically to extract target posi- 
tion and range rate (radial velocity) data. A 
verification track on the target began when the 
range rate and position predictions satisfied 
preselected criteria for range velocity and 
track initiation volume. Search scanning con- 
tinued independently of the other functions. 


_ An operator could overrule the automatic 
function to initiate verification tracking manu- 
ally on a target of his choice. In either case, 
the successful verification of a threat changed 
the mode from surveillance to engagement. In 
the engagement mode, search and verification 
tracking continued at a faster search scan rate. 
In addition, the precision tracking and discrimi- 
nation functions became available. 


Discrimination data were obtained by either 
manually or automatically positioning the radar 
coverage of a threat tube. Each threat tube 
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was divided into subtubes, each formed by a 
separate radar beam. The widths and center- 
to-center spacings of the beams were controlled 
as functions of range to provide constant-volume 
coverage independent of range. The discrimina- 
tion transmitter beam was a single beam broad- 
ened to illuminate the entire threat tube. -- 


A precision tracker was assigned and given 
target position estimates from the verification 
tracker. Verification tracking was thus a 
prerequisite for precision tracking and termi- 
nated after the precision tracker locked on the 
target. Except for a pulse-~compression wave- 
form that increased range resolution, the two 
track processes were essentially the same. 


MAR-I was divided into ten major subsys- 
tems, as shown in Figure 2-7. They are 
briefly described below. 36 


Transmitter Antenna 


The transmitter antenna consisted of active 
elements forming a circular planar array, with 
elements arranged as the vertices of equilateral 
triangles. Each element was fed by an indi- 
vidual power amplifier in the transmitter. The 
transmitter array was housed in a concrete 
dome structure so that the array normal was 
elevated 38.5 degrees above horizontal. MAR-I 
had one transmitter array. 


Receiver Antenna 


The receiver antenna consisted of elements 
in a circular array, each element followed by 
a low noise preamplifier which was part of the 
receiver. MAR-I had one receiver array. 


Transmitter 


The final power amplifiers were specially- 
designed high-gain traveling-wave tubes. 
Delay matrices consisting of switching diodes 
and strip lines performed beamforming and 
steering. Search, track, and discrimination 
pulses at different frequencies were trans- 
mitted in a single pulse chain. 








TOY LNOOD 
ONY 
ONISSS00Ud 
vivd 
TWHYLNID 


NOILVOO1 
Linvd 


ONIYOLINOW GNV 
NOILV¥SINVS du 







wesbeig yoojg jeuolzgUNy |-YWW ‘L-e 84nbly 


ONISS3IO"d TVNOIS 
GNvV 


SAV 1dSid 
SdWNV JT SdWV AI 
GNV Y4XIW GNv YSXxIW 
TOYHLNOOD 
yuvav" zl 


sig 
dsia 





SdNV 
ALVIGSWYILNI 


VNN3LNV YSLLINSNVYL 


VNNSLNY Y3SAIZ9034 


SdWV AT 


GNV Y4XIW- 





2-20 





Receiver 


The receiver operated on three separate 
channels, one each for the search, track, and 
discrimination functions. Each channel had 
its own beamforming and steering circuits 
and its own unique beam and cluster configura- 
tion. The incoming signals from the antenna 
elements were fed through individual pre- 
amplifiers to power dividers which provided 
signals to the three channels. After beam- 
forming and steering, the three mixing cir- 
cuits (search, track, and discrimination) 
converted the RF signals to IF signals at 
different frequencies. These signals were 
then amplified in the IF amplifiers and sent 
to signal processing. 


Signal Processing 


Signals were processed in two basic units: 
the Search Signal Processor (SSP) and the 
Video Pulse Converter.(VPC). The SSP indi- 
cated initial target detection and determined 
range, range rate (by doppler shift), and 
angular position. These parameters were fed 
to displays, recorders, and central data 
processing and control. 


The VPC processed the outputs of the receiver 
track detectors and video amplifiers, converted 
the desired information to digital form, and 
converted search and discrimination video to 
digital form for test purposes. The pulse- 
compression networks for the precision track and 
discrimination functions were part of the signal 
processing subsystem. 


Radar Control 


Radar control, under instructions from cen- 
tral data processing and control, coordinated 
and controlled some of the activities of MAR-I. 
It generated and selected local oscillator fre- 
quencies and modulation parameters and con- 
trolled the beamforming and steering networks. 


2-21 


Displays and Recording 


Operators at display consoles monitored 
system operations and performed some MAR-I 
functions which would have been automatic in a 
tactical MAR. The MAR-I display and recording 
subsystem had four operator positions, which 
monitored and reported on system status,-con- 
trolled search and track assignments, positioned 
the discrimination cluster for sub-beam selec- 
tion, and controlled recording. 


Fault Location and Monitoring 


MAR-I used a Fault Location and Monitoring 
(FLAM) subsystem for more efficient mainte- 
nance and to minimize down time. The subsys- 
tem monitored the system to detect faults, 
indicated the existence and rack location of each 
detected fault, and automatically recorded fault 
occurrences. 


RF Calibration and Monitoring 


The RF calibration and monitoring subsystem 
measured the overall amplitude and phase trans- 
fer characteristics of individual channels in 
the phased array. Various routines were 
measured for all combinations of input channels 
and beam outputs, and faulty components were 
located by these measurements. In most cases 
measurements did not interfere with normal 
operations. In the transmitter, the transmitted 
search pulses were used for monitoring; in the 
receiver, a calibration pulse was inserted 
during ranging dead time just before the next 
transmitted pulse. 


Central Data Processing and Control! 


The Central Data Processing (CDP) and Con- 
trol Subsystem had three basic units: Control 
Switch and Buffer (CSB), Tape Buffer System 
(TBS), and General Purpose Digital Computer 
(GPDC). The CDP sorted and routed all data 
flowing between the GPDC and the other units 
of MAR-I and also performed system timing. 


The TBS served as a buffer memory be- 
tween the GPDC and input/output devices. Out- 
put devices were magnetic tape units, flex- 
writers, and a high-speed line printer. The 
former two units were also used as input de- 
vices. 


The GPDC processed large quantities of real- 
time data, and the computer operated in the 
fixed-point parallel binary mode with a 24-bit 
word format. Instructions were single address 
with a minimum execution time of 2.5 micro- 
seconds. 


Multifunction Array Radar (MAR-II) 


As discussed earlier in this chapter, NIKE-X 
was to be an autonomous system capable of 
fully-automatic, instantaneous, and effective 
response to a wide variety of offensive tactics 
and intensities of ballistic missile attack. Its 
main radar was to be the MAR. The MAR com- 
bined search, verification track, discrimination, 
precision track, and defensive missile track 
and guidance into a single phased array operating 
at L-band. 


By mid-1967, the ABM defense objectives of 
NIKE -X were directed to defending CONUS 
against light attacks. This shift from local 
defense against high-traffic, sophisticated 
penetration-aided attacks culminated in a de- 
cision to concentrate on the lower cost auto- 
nomous MSR as the primary terminal defense 
sensor. On this decision the development of 
MAR and its Kwajalein prototype (MAR-II) was 
terminated. 


Initially, it was planned that NIKE-X would be 
tested at the Kwajalein Missile Range and involve 
two phased-array radars: the MSR and the 
MAR.” The latter was to have reduced capabili- 
ty, but could be retrofitted to full MAR capability 
later. The Kwajalein version of the MAR, 
designated MAR-II, was to be a sSingle-faced 
(single transmitting antenna array and single 
receiving antenna array) radar. 


. sophisticated threat. 
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To retrofit MAR-II with minimum down time, 
all-of its transmitter and receiver elements 
and associated cabling would be installed initi- 
ally. To reach full MAR capability, the addi- 
tional transmitting and receiving hardware, 
waveform generation equipment, signal proc- 
essors, etc., would be installed, checked, and 
then connected to the antenna elements. 


TACMAR 


Originally, two versions of the MAR were to 
be used in NIKE-X. The MAR was to be a 
higher powered radar, with a full complement 
of transmitting and receiving antenna elements. 
The second version, TACMAR,*”® had only 
half as many active antenna elements as MAR 
for both transmitting and receiving. TACMAR 
thus had approximately half the power output, 
lower receiver performance, and a proportion- 
ately lower range. It could produce fewer 
waveforms and therefore had a reduced dis- 
crimination capability. This radar was de- 
signed to be cost effective in the less demand- 
ing defense against an early, relatively un- 

It was to be used for 
high-confidence, early detection of ensemble 
attacks, for detecting RVs with small radar 
cross sections at intermediate ranges, and for 
supporting ZEUS area defense and SPRINT 
local defense.’ If the need developed, TACMAR 
could be augmented to full MAR capability. 


MAR/TACMAR Subsystems 


MAR and TACMAR were divided into six 
major subsystems, as shown in Figure 2-8. 
They are briefly described below.>** | 


Antennas 


In TACMAR, each of the two transmitting 
antenna arrays contained active elements 
arranged in a concentric hexagonal configura- 
tion with one element in the-center. In addi- 
tion, passive elements were mounted in the 
array face so that TACMAR could later be 
augmented to a full MAR. 
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Figure 2-8. TACMAR Block Diagram 
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RECEIVER 






Transmitter 


The transmitter chain generated and radiated 
high-power pulses and pulse trains with the cor- 
rect waveforms for various radar functions. 
Real-time delay boards, with diode bit switches 
directed by radar control, formed and steered 
beams. After high-power amplification by 
traveling wave tubes, , the signal went to the 
transmitting elements through an RF face 
selection switch. 


Receiver 


The output of each element of the receiving 
antenna array was connected to a preamplifier 
module. The module had a transistor ampli- 
fier, level control attenuators, a second tran- 
sistor amplifier stage, and a phaSe equalizer 
unit. The output of the module was connected 
to the Beamforming and Steering (BFS) equipment 
which was of the fan-multiplex MOSAR type. 

The BFS circuits steered the multiple beams 
formed by the receiver. These circuits had an 
output for each of the 40 discrimination beams 
(nine of which formed the search cluster) and the 
three monopulse track beams. Digital inputs 
from radar control controlled the BFS equipment. 
The local oscillator signals, which were used in 
the mixers to reduce the received L-band signals 
to intermediate frequency, were formed in the 
exciter-stalo. 


The input module of the BFS section included 
the face switch directed by radar control to 
switch receiver operation to either antenna- 
preamplifier face. The received signal output 
from the BFS section went to the signal pro- 
cessor. 


Signal Processor 


The signal processor accepted outputs from 
the receiver and converted them to forms for 
the radar function that the Defense Center Data 
Processing System (DCDPS) was analyzing. 
The signal processor also accepted pulses 
from the missile beacon and identified or re- 
jected spurious signals introduced by noise, 
countermeasures, or sidelobes. 
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Radar Control 


Radar control provided communications be- 
tween the MAR and DCDPS. It executed 
DCDPS's Central Logic and Control (CLC) 
orders concerning pulse selection, transmitter 
and receiver BFS equipment, frequency selec- 
tion, and power levels. Radar control furnished 
timing information to the subsystem elements 
and accepted fault location information, which 
it relayed to the monitor. 


Monitor 


The monitor detected system degradation, 
calibration drifts, or failures that required 
replacement of a unit. Also, if the failed unit 
was a critical item, the monitor took corrective 
action by switching in a redundant unit. System 
degradation was reported via displays and 
printouts. The monitor had two major parts: 
RF Calibration and Monitoring (RFCM) and 
Fault Location and Recording (FLAR). 


Conclusion 


By mid-1967, the ABM defense objectives 
of NIKE-X were directed to the area defense of 
CONUS against light attacks. This shift from 
local defense against high-traffic, sophisticated 
penetration-aided attacks culminated in a deci- 
sion to concentrate on the lower cost, autono- 
mous MSR as the primary radar for terminal 
defense. Hence, the development efforts on 
MAR, the Kwajalein prototype (MAR-II), and 
TACMAR were terminated. 


As stated earlier, the fundamentais of 
phased-array antennas and beamforming were 
well understood when MAR-I was conceived, and 
the only real question concerned the application 
of phased arrays to a multiplicity of simultane- 
ous functions. Thus, the paramount lesson 
learned from MAR-I was that the program veri- 
fied the analytical predictability of array per- 
formance in a multifunction role. 


Of equal, if not greater, importance was 
identifying the significant problems that re- 
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sulted from attempting to verify hardware and 
software on site, with an operational system, 
without the support of either a hardware or 
software testbed. This was especially apparent 
with the array hardware. Unit level tests of 
either single elements or a small sampling of 
elements with their associated hardware ap- 
peared to be trouble-free. However, when these 
tests were integrated into the complete system 
consisting of thousands of elements with their 
associated signal and power cabling, adverse 
interactions occurred. A hardware testbed for 
simulating the physical and electrical character- 
istics of a full array might have averted the 
problem. Software testing presented a similar 
problem, since development and test were done 
by computer simulations of the expected data 
processor-radar hardware interface. A software 
testbed that duplicated the interfaces would no 
doubt have uncovered most of the problems with 
the on-site software installation. Partly because 
of this MAR-I experience, the Tactical Software 
Control Site (TSCS) concept was adopted for 
SAFEGUARD. TSCS called for the development, 
integration, and evaluation of tactical software 
in a testbed that duplicated the on-site data 
processors and radar interface hardware. 


GUARDIAN (FORMERLY CAMAR) PROGRAM 


During the mid-1960s, measurements taken 
by field radars on reentering bodies had shown 
an enormous growth in both quantity and sophisti - 
cation. This information strongly stimulated 
research in discrimination techniques. Despite 


_ vigorous efforts to develop a better theoretical 


understanding of the fundamental phenomena in- 
volved in reentry, the physics of it remained 
largely an empirical science. By 1968 the 
success of discrimination research created 

the need to construct a real-time discrimination 
capability and to demonstrate its effectiveness 

in a realistic traffic environment. To demon- 
strate discrimination capability required a radar 
and data-processing facility that could perform 
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a variety of interactive functions. It was not 
sufficient merely to implement, in real time, 
the simple target -oriented discrimination 
techniques that were successful in post -flight 
data analyses, because a credible ABM dis- 
crimination depends on a sequence of inter- 
related events, such as, : 
© Determining the bounds of the threaten- 
ing complex to predict the bounds and 


eae of threat tubes to be searched for 
s 


® The automatic techniques which acquire 
and track objects as they emerge from 
tank breakup clutter or chaff clouds 


e The ability to cope with large numbers of 
traffic decoys and deployment hardware, 
so that the more likely RV objects can be 
identified and scheduled for sophisticated 
discrimination processing 


@ The ability to maintain track reliability in 
the presence of crossing targets and nu- 
clear perturbations 


e Applying the sophisticated discrimination 
waveforms and associated signal process- 
ing to finally discriminate the RVs 


e@ Real-time management of site resources 
(radar, data processing, and missile 
stockpile) to effectively allocate them in 
the presence of traffic overloads. 

A program (initially labeled CAMAR, for 
Common Aperture Multifunction Array Radar, 
and renamed GUARDIAN) was started to 
identify the needs of the ABM community and 
Significantly advance understanding in these 
areas of the discrimination system problem. 


Program Objectives 


The intent of the GUARDIAN (CAMAR) pro- 
gram was to produce the technological base and 
experience from which an urban terminal or 
hardsite defense system could be developed. 

The program involved the development and 
implementation of a system testbed facility 

at Bell Laboratories, Whippany, and a radar and 
data processor at Kwajalein that could search, 
track, discriminate, and intercept actual 
penetration-aided threats. 


GUARDIAN's basic thesis was that the various 
ABM system functions could not be developed 
outside the context of the integrated system. 


Furthermore, because of their complicated 
interdependence, these functions, taken as a 
whole, could not be developed, integrated, and 
evaluated through the usual approach of a proto- 
type field site demonstration. Therefore, to 
develop and evaluate the hardware/software 
forming the integrated system, it was planned 
that a high-fidelity testbed be built at Bell 
Laboratories in Whippany, N. J. All low-level 
radar subsystems and a complete Data Process- 
ing and Control Computer (DPCC) were to be 
incorporated in the testbed. To drive the test- 
bed, an extensive radar simulator and threat 
generator were to be developed. 


Thus, the GUARDIAN proposition was (1) that 
the exploratory development planned for 
GUARDIAN could only be accomplished with a 
flexible, high fidelity testbed and (2) that the 
field site pseudo-prototype would have two 
roles: to measure the environment and charac- 
terize radar performance in supporting the 
testbed development, and to "certify" testbed 
results through demonstration exercises. 


With these objectives, two distinct phases 
were planned for the Kwajalein experience. 
The first was the Measurement and Recording 
(MR) role and the second the Discrimination 
Demonstration (DD) role. The MR role, 
primarily a real-time recording activity, was 
to supply supporting data for developing the 
testbed and discrimination algorithms. The 
DD roles were primarily concerned with demon- 
strating, in real time, functions developed with 
the aid of the testbed. 


Development Progress - 


By early 1968 the requirements for the testbed 
and its target and radar environment driver had 
been established, and the testbed was under 
development. This involved planning the inter- 
connection of the data processor, the low-level 
radar subsystems, and the radar target/environ- 
ment simulator. Target threats and specific 
target environments were defined early in the 
program. The time-phased sequence of mis- 
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sions to exercise and evaluate the system had 
also been planned. 


As a consequence of the NIKE-X I-67 
(SENTINEL) decision, the very high traffic, re- 
gional coverage capability of the MAR was no 
longer needed. Therefore, in April 1968, the 
MAR/TACMAR development and the MAR-H pro- 
totype work at Kwajalein were redirected to the 
GUARDIAN program. MAR's basic elements 
were used in designing CAMAR, the field site 
radar of the GUARDIAN program. The major 
subsystems of CAMAR were: 

e Array Subsystem. This used a common 
aperture that functioned as both trans- 
mitter and receiver. A beam steering 
translator controlled the phase shifters 


and converted steering orders from the 
Data Processing Control Computer. 


e@ Transmitter Subsystem. The waveform 
generator, exciter, and stalo were con-. 
trolled by the data processor. The radar 
control processor selected from among 
six waveforms and associated signal 
processors. 


e Receiver Subsystem. The receiver input 
was a low-noise parametric amplifier. 
The receiver was to form a three-beam 
cluster for search and designation and a 
four-beam monopulse cluster that could 
be broadened for track. 


e Signal and Report Processor. Individual 
processors were provided for the six 
waveforms. 


Development Plan 


GUARDIAN's MR role was scheduled for 
early 1972 and the DD role by late 1973.""" The 
test and evaluation phase was to consist of two 
parts: 

1. Testing the radar to ensure that it met 

requirements 


2. Evaluating the entire radar-computer 
system to establish that -it performed 
the DD role as intended. 


Demise of the GUARDIAN Program 


By early 1969 the program received the 
name GUARDIAN; its radar continued to be 
designated as CAMAR. During this period 
serious consideration was given to modifying 
the testbed objectives to directly support 


deployment of advanced hardsite defense sys- — 1. A prototype of a site-defense system 


tems.” This implied a possible change in the would be developed. 
2. Recognizing the inadequacy of the tech- 


GUARDIAN radar. Therefore, design of hard- nological and phenomenological data base 
ware and software sensitive to the choice of of the discrimination and bulk filter _ 
radar frequency was curtailed from mid-June functions, the Lincoln Laboratories dis- 


crimination development and demonstra- 
onward.” This was essentially the end of the tion effort, employing the Kiernan 


GUARDIAN program. Shortly thereafter the Reentry Measurement Site (KREMS) at 


. ; : Roi-Namur, was to be accelerated. ~ 
Army decided that design of a terminal ABM With this redirection toward a directly de- 


would proceed in Birentions ait ereut from the ployable system design, the GUARDIAN ex- 
GUARDIAN program in two significant ways: ploratory program was set aside. 
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The SENTINEL System was formulated to de- 
fend against the potential ICBM threat from both 
the Chinese People's Republic (CPR) and the 
USSR during the 1970s. The deployment decision 
limited its initial role to a complete area defense 
against a CPR industrial/urban attack on the Con- 
tinental United States (CONUS), and contained a 
growth option for defending certain U.S. ICBM 
bases against USSR attack. Damage prevention 
was the defense objective against a credible CPR 
attack while damage limitation was the defense 
objective against a future expanded CPR threat 
and against a USSR counterforce attack on major 
Minuteman installations. 


The SENTINEL System evolved from the 
NIKE-X program, specifically the I-67 System 
Study.'-? The objectives of this study were to: 

e Devise a defense against a countervalue 

attack with ICBMs from the CPR 


e Provide for defense against a counterforce 
attack with ICBMs and SLBMs from the 
USSR 

e Hold total system investment costs to $5 
billion 

@ Meet an Initial Operational Capability (IOC) 
date within 54 months of a deployment de- 
cision. (This requirement limiting the 
choice of system elements to NIKE-X 
equipment. ) 


The study concluded that a system consisting of 
modified NIKE-X subsystems deployed at 


3-1 


Chapter 3. 
SENTINEL SYSTEM 


installations within CONUS and on Hawaii would 
meet these objectives. 


In September 1967, the decision was made to 
proceed with the development, production, and 
installation of this system — given the project 
name SENTINEL. Further studies led to rela- 
tively minor modifications of the components and 
deployment called for in the I-67 System Study. 
It was also decided to give first priorities to the 
installations necessary for an area defense 
against a CPR attack. This deployment would 
then be augmented later to defend Minuteman 
sites against a USSR attack. 


SYSTEM DESCRIPTION 


The SENTINEL System consisted of the follow- 
ing major subsystems: 


e Perimeter Acquisition Radar (PAR) and 
associated PAR Data Processor (PARDP) 
for long-range surveillance and tracking 
of attacking ICBMs 


@ Missile Site Radar (MSR) and associated 
Missile Site Data Processor (MSDP) for 
close-in target surveillance and tracking, 
and for command guidance of defensive 
missiles 


@ SPARTAN missiles With high-yield nuclear 
warheads for long-range intercepts 


e@ SPRINT missiles with low-yield nuclear 
warheads for close-in, fast response 
intercepts 


e A Command and Control structure linking 
these elements. 


Deployment 


The initial SENTINEL deployment, to provide 
an area countervalue defense of CONUS and 
Alaska, was to consist of 6 PARs, 16 MSRs, 480 
SPARTANS, and 192 SPRINTs. An additional 
MSR and 28 SPRINTs were to be provided for 
Hawaiian defense. The PARs would have their 
single arrays generally faced to the north. The 
MSRs would have one, two, or four array faces 
depending on their location and role in the de- 
fense. This initial deployment could grow to in- 
clude defense of strategic missile bases by the 
addition of 208 SPRINTs and modification of the 
data processing hardware and software at the 














This system was to be closely netted and would 
have the ability to modify its response to specific 
attacks. Overall command and control, admini- 
stration, and status of the system was to be ef- 
fected through netting of local and area defense 
centers and, these in turn, with the Continental 
Air Defense Command (CONAD). This deploy- 
ment is depicted in Figure 3-1. _ 


Area Coverage 


The area defense provided by the SENTINEL 
deployment involved nearly complete coverage of 
the contiguous United States, as well as parts of 
Alaska and Hawaii, against the defined CPR 
threat.‘ 


The defensive coverage planned for each 
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sites located near Minuteman bases. SPARTAN firing site is depicted in Figure 3-2. 
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Figure 3-1. Locations of Sites for SENTINEL Deployment 
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Figure 3-2. Ground Impact Area Coverage 


The contour shown encloses the impact points of 
attacking ICBMs which could be intercepted above 
the atmosphere by a SPARTAN launched from that 
site. In general, the coverage (sometimes called 
a "footprint") was limited in the forward direc- 
tion by the PAR detection range, and to the side 
and rear by a combination of missile capability 
and MSR scan limits.$ 


Achieving an effective area defense depends 
on the ability to search and detect objects at 
ranges that provide sufficient time to launch an 
interceptor at the attacking ICBM. This function 
of long-range search and detection would be per- 
formed by the Perimeter Acquisition Radar. 
Five PAR installations were to be located along 
the northern periphery of the United States, with 
one additional installation in Alaska. *’ The PARs 
would also have a verification and tracking ca- 
pability to provide trajectory information to the 
missile firing sites and to command and control 
centers. 
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The SPARTAN missile firing sites, each with 
an MSR, were located in sucha manner that their 
defended area footprints encompassed the entire 
CONUS. The SPARTAN firing site in Alaska 
provided a defense for most of the population 
there, while a SPRINT firing site on Hawaii pro- 
vided almost complete area coverage of Oahu. 


Collocated with each of the six PARs was a 
missile firing site using SPRINT to provide a 
high-confidence, terminal-intercept capability 
for the defense of these forward radars. 


Minuteman Defense Coverage 


The SENTINEL deployment called for growth 
to provide a terminal (SPRINT) defense of Minute- 
man squadrons at five bases. ** The deployment 
objective was the maximization of silo coverage 
and survival against a large USSR attack. 


The defense coverage to be provided, as con- 
trasted with area defense, was strongly depen- 
dent on the characteristics of the threat, the 
actual site locations, and the level of deployment. 
Of particular importance was the target commit 
altitude, i.e., the altitude of the target at the 
time of launching a defensive missile. The com- 
mit altitude was determined by radar coverage, 
system response against a specified threat, and 
defensive missile fly-out time. 


Remote launch of SPRINT was specified for 
the Minuteman defense sites to minimize fly-out 
time. These remote missile farms were located 
near the Minuteman silos at distances of about 25 
miles from the MSR. 


The SPARTAN missile, in addition to its area 
defense role, provided additional protection of 
Minuteman bases. : 


Command and Control 


Of importance to the system operation and re- 
sponse was the concept that Command and Control 
should be designedto allow appropriate authority to 
reside atthe lowest levelin the command hierarchy, 
consistent with the level at which available data 
would support system functions and decisions.!° 


The SENTINEL Command and Control is il- 
lustrated in Figure 3-3. The system was to op- 
erate under a three-level hierarchy of Command 


trol of an ACC. The MDC was responsible for 
MSR control, SPRINT command and control, 
and/or SPARTAN control.!° 


and Control headed by the Ballistic Missile De- 
fense Center (BMDC) which was the interface 
point between SENTINEL and CONAD. The BMDC 
was to be the command point through which the 
Commanding General of the Army Air Defense 
Command (ARADCOM) would exercise command 
and technical supervision over the SENTINEL Sys- 
tem.!! The BMDC was charged with defense of 
the entire United States through coordination 

with three Area Control Centers (ACCs) under 

its command./?_ The ACC responsibilities in- 
cluded PAR command and control,!3 MSR com- 
mand,!4 and SPARTAN command. Missile 
Direction Centers (MDCs) were grouped on an 
area basis with five or six MDCs under the con- 


The three ACCs were collectively responsible 
for three areas of CONUS. The boundaries be- 
tween areas were drawn to minimize SPARTAN 
coverage overlays and to provide necessary co- 
ordination. Each primary ACC had an alternate 
as shown in Figure 3-4 which illustrates the 
MDCs and PARs included in the command and 
control structure of ACC No. 2. Here, the pri- 
mary ACC was located at Warren AFB and the 
alternate was located at Whiteman. A failure at 
Warren resulted in a preplanned, progressive 
sequencing of control to Whiteman. 


Communication circuits were to be provided, 
for both voice and data, with two geographically 
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Figure 3-3. SENTINEL Command and Control Structure 
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Figure 3-4. Area Control Center Number 2 


separate paths required for all links. Inter- 
area communications were to be provided only 
between ACCs, with PAR data being sent to the 
BMDC via the ACC; MSR data were to be sent to 
the controlling ACC for inter-area MSR coordi- 
nation and threat evaluation. 


System Operation and Response 


Long-range surveillance and target tracking 
in the SENTINEL System were to be provided by 
the PAR. For urban defense, the SPARTAN was 
the primary interceptor and was tracked and 
guided by MSRs. Minuteman defense would be 
accomplished largely as a terminal defense with 
SPRINT, supplemented by SPARTANs, contribut- 
ing where they could be effectively brought to bear. 


Generally, targets would be detected first by 
the PARs and, after a few seconds of tracking, 
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trajectories and impact points would be deter- 
mined and an MDC designated. For SPARTAN 
intercepts, target information relative to inter- 
ception would be continually refined and passed 
to the appropriate point. The MSR, in some in- 
stances, would acquire and track the target 
prior to SPARTAN burst and thus reduce the 
intercept error. 


For SPRINT engagements, the PAR data 
would be passed to the assigned MDC for sub- 
sequent action once the local MSR had established 
track. For terminal defense, the MDC could 
act autonomously with the MSR providing target 
surveillance and acquisition, as well as target 
and missile track. 


For area defense, the SPARTAN engagement 
would be planned at the ACC and take into account 
blackout and fratricide constraints, defensive 
missile stockpile balance, and other restrictions. 


The ACC would determine effectiveness against 
possible follow-on attackers. Allocation thresh- 
olds would be set and the stockpile balance 

among SPARTAN firing sites adjusted according- 
ly. The intercept would be planned specifying the 
place, the time, and how many SPARTANs were 
to be used in meeting effectiveness criteria. 
Continuous evaluation of the engagement plan 
would be provided to ensure its adequacy. The 
BMDC would coordinate the roles of the ACCs and 
provide information on estimated future attack 
size and defense objectives. Implementation of 
the SPARTAN engagement plan would be per- 
formed by the MDC, including post-intercept 
evaluation for use at the ACC. 


For Minuteman defense, the BMDC would pro- 
vide information to the ACC as in area defense, 
together with any Minuteman silo coverage 
constraints on the defense. The ACC would de- 
termine the division of the total attack for 
SPARTAN and/or SPRINT engagement assign- 
ments. These assignments would be sent to the 
designated MDCs where engagement plans would 
be completed. Any conflicts involving fratricide 
or blackout between SPARTAN and SPRINT would 
be resolved by the MDC. The MDC would also 
select the SPRINT farm to be used and plan the 
engagement to achieve the effectiveness level 
specified by system objectives, including pref- 
erential defense of Minuteman and the SENTINEL 
complex. 


System Readiness Verification: 


The SENTINEL System design was strongly 
influenced by stringent availability/reliability 
objectives, that is, requirements for high prob- 
ability that the system would be available if an 
attack should occur, coupled with requirements 
for high reliability during an attack.!5-!* The 
design intent was to provide a built-in capability 
for comprehensive testing of all system elements 
to provide continuous confidence in the system's 
readiness to perform its mission. This led to 
requirements for developing a large array of 
subsystem, functional, and hardware tests. In 


addition, a system exerciser would test the fully- 
integrated system, partially by simulation. The 
collection of hardware and software required to 
provide this built-in test capability was referred 
to as System Readiness Verification (SRV).?° 


The SRV tests were oriented toward providing: 


e Verification that critical system perform- 
ance parameters were within specified 
limits 

@ Detection, isolation, and indication of 
hardware faults 


e Verification that the dynamic response of 
individual and collective sites (including 
hardware, software, and personnel) to 
design-level attacks was correct and that 
predetermined results were obtained. 

In the PAR and MSR, fault detection tests 
were designed to run cyclically during the radar 
pulse-cycle dead-time while the system was per- 
forming its major role. If test results did not 
meet specified limits, spare groups of equipment 
would be automatically switched in while monitors 
indicated the faulty equipment. Additional fault 
detection and isolation tests were provided for the 
off-line equipment. 


Data Processing System (DPS) hardware was 
checked by periodically scheduling units (proc- 
essors, mémories, etc.) off-line for testing by 
the Maintenance and Diagnostic Subsystem. A 
fixed set of tests was applied to each unit, re- 
sults analyzed, and, in most cases, the fault 
identified. 

For SPRINT and SPARTAN, special test pro- 
grams were periodically run in the DPS to , 
exercise missile subsystem hardware via normal 
interface channels. Monitors would indicate if the 
tests were unsuccessful and additional tests would 
be run to isolate the fault. 


A System Exerciser provided the means for 
additional testing of system hardware as well as 
for exercising the tactical software (known as the 
weapons system process). This was accom- 
plished by partitioning the DPS equipment at each 
site into two separate data processors — one to 
simulate a specified threat and the other to re- 
spond as during a real engagement. During an 
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exercise, the simulator would generate radar 
returns representing the preselected attack for 
injection into the radar receivers. The system 
would respond in a normal manner except that 
simulated defensive missiles would be launched 
and guided under control of the weapons system 
process. The results of the exercise would be 
checked to make certain that the engagement 
proceeded as expected. 


The System Exerciser concept also provided 
the means for developing and testing software in 
the SENTINEL Data Processing Laboratory 
(SDPL) at Whippany, where site equipment was 
either duplicated or simulated. Similarly, the 
System Exerciser would provide the major tool 
for integrating and testing software at tactical 
sites. 


SYSTEM REQUIREMENTS AND DEVELOPMENT 


Documentation 


The basic requirements for the SENTINEL 
System and its major components were developed 
during the initial system studies (e.g., I-67 Sys- 
tem Study) and refined during the first phase of 
system development following the deployment de- 
cision. These requirements evolved into a hier- 
archy of performance/design specifications which 
were to be prepared by Bell Laboratories and 
approved and placed under configuration- 
management control by the Army.?! The func- 
tional organization and objective of these speci- 
fications were: 


e SENTINEL System Specification — included 
threat parameters, overall performance 
requirements, deployment plan, radar and 
missile types and locations, and a list of 
sub-specifications. 


e Hardware Oriented Specifications — one 
each for the PAR, MSR, BMDC, Data 
Processor, and SPARTAN and SPRINT 
with their associated equipment; perform- 
ance requirements and design character- 
istics were included in each document. 


e Specifications for Maintenance Facilities — 
stipulated requirements for Test Equip- 
ment, Maintenance Data System, and Sys- 
tem Readiness Verification. 


e Software Oriented Specifications — one 
each for the programs in the MSDP, 
PARDP, BMDC, and System Readiness 
Verification; requirements for inputs, out- 
puts, operations, and major functions were 
included in each document. 


These specifications were also used in the 
contractual requirements placed on the major 
subcontractors for the radars and missiles. - 


System Engineering 


System engineering activities were primarily 
concerned with definition, documentation, and 
specification of the SENTINEL System operational 
requirements. Simulations were developed for 
evaluating tactical concepts and system effective - 
ness? A mathematical model was prepared to 
simulate, in a computer, the proposed SENTINEL 
deployment to evaluate the complete system de- 
sign and interaction among its various parts .23-?? 
As data from MSR and MSDP tests at Meck Island 
and from SPRINT and SPARTAN firings became 
available, they were introduced into the simula- 
tion to increase the accuracy of results. 


Missile Site Radar 


The Missile Site Radar (MSR), an S-band 
single-beam, phased-array radar, was used 
with the Missile Site Data Processor (MSDP) to 
perform surveillance and limited discrimination, 
track of reentry targets, and track and command 
guidance of SPRINT and SPARTAN missiles.2* 
The Raytheon Company, Bedford, Mass., was 


. the MSR subcontractor with Bell Laboratories 


providing overall direction, design control, and 
assistance in critical areas. 


The MSR was structurally a part of the Mis~ 
sile Site Control Building which also housed the 
MSDP. It was designed to have one, two, or 
four antenna faces inclined 51.5 degrees from the 
horizontal. Each face was used for both trans- 
mitting and receiving, with a single transmitter 
and a single receiver time-shared among faces. 
The transmitter (up to the final klystron ampli- 
fiers) and the receiver had duplicate equipment 
and automatic switching for redundancy. The two 


final klystron amplifiers were operated in 
parallel] but also could operate alone at reduced 
power. Face switching and beam forming and 
steering were computer controlled. 


With the change to SENTINEL, the autonomous 
role of the MSR was expanded, thus necessitating 
major changes to upgrade its tracking capability. 
An example of this change was the required five- 
fold increase in its output average power level. 

A prototype MSR with two array faces was con- 
structed on Meck Island and tested extensively. 
This test program provided significant data use- 
ful in the design of the follow-on SAFEGUARD 
System. 


Perimeter Acquisition Radar 


The Perimeter Acquisition Radar (PAR), a 
single-beam, phased-array radar, was used 
with the PAR Data Processor (PARDP) to per- 
form long-range surveillance, target verifica- 
tion, and tracking of attacking ICBMs.2? The 
requirements specified a maximum detection 
range sufficient to allow time for SPARTAN 
missiles to intercept warheads outside the at- 
mosphere, The PAR initially was planned as an 
“off the shelf’ VHF-band radar, but following.a 
study on the effects of nuclear blackout,* the 
frequency was changed to the UHF band, necessi- 
tating an extensive redesign program. 


PAR was designed to operate in a hostile en- 
vironment consisting of false targets (aircraft, 
satellites, meteors, or aurora), clutter signals 
(from the ground, chaff, or aurora), and nuclear 
disturbances (electromagnetic pulses, blast 
waves, ground shock, thermal radiation, and 
other radiation from nuclear weapons). 


Development of the PAR was divided into 
three phases as follows: 


PhaseI — Performance definition and equip- 
ment specification 
Phase I — Design and manufacture of a pro- 


totype at a site near Boston 


Phase II — Production and deployment of 
the remaining five radars. 
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The General Electric Company, Syracuse, 
New York, was responsible for PAR development 
under subcontract to Bell Laboratories. At the 
time the decision was made to reorient SENTINEL 
System development to SAFEGUARD objectives, 
the prototype site near Boston was underway and 
had to be moved to Cavalier, North Dakota. 


SPRINT Missile Subsystem 


SPRINT, a two-stage, solid-propellant 
missile, was the interceptor for terminal de- 
fense in the SENTINEL System. It was de- 
signed to be extremely fast reacting and capable 
of delivering a nuclear warhead to an intercept 
point, at short ranges, within seconds after 
launch}! 


Development test firings of SPRINT were 
first conducted at White Sands Missile Range as 
part of the NIKE-X program. Later SPRINT 
launches at Meck and Illeginni Islands were con- 
ducted using SENTINEL MSR/MSDP guidance in 
SAFEGUARD System missions. 


The Martin Marietta Corporation, Orlando, 
Florida, was the subcontractor to Bell Labora- 
tories for development of SPRINT. Missile- 
borne guidance equipment was developed by Bell 
Laboratories and manufactured by Western 
Electric. 


SPARTAN Missile Subsystem 


The SPARTAN missile, in its primary role, 
provided long-range, large-payload, intercept 
capability against exoatmospheric targets.” 

The three-stage missile employed booster and 
sustainer motors to achieve peak velocity and a 
third-stage controllable jet motor for final inter- 
cept control. 


Design and development of SPARTAN was the 
responsibility of the McDonnell Douglas Corpor- 
ation, Santa Monica, California, under subcon- 
tract to Bell Laboratories. Guidance equipment 
for SPARTAN was developed by Bell Laboratories 
and manufactured by Western Electric. 
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Many of the basic design features of the NIKE- 
ZEUS DM-15C missile were used in SPARTAN. 
Design emphasis for use in SENTINEL was con- 
centrated on those areas in which changes had to 
be made to carry a heavier warhead for the 
longer range, barrage-type function of SPARTAN. 


The SPARTAN missile development flight-test 
program began at Kwajalein in March 1968 and 
continued into 1969. Use of SPARTAN in 
SAFEGUARD system missions began in April 1970. 


Data Processing 


Each SENTINEL installation included a Data 
Processing Subsystem which controlled the 
functioning of its radar (PAR or MSR), analyzed 
attacks, allocated system resources, and com- 
manded the launch and guidance of interceptor 
missiles 33 


Two R&D versions of partial data processing 
subsystems were installed: the SENTINEL Data 
Processing Laboratory (SDPL) at Whippany, and 
a minimum Missile Site Data Processing Subsys- 
tem (MSDPS) at Meck. The SDPL was uded for 
equipment evaluation and software program de- 
velopment; the MSDPS was integrated with the 
MSR and used for MSR testing and performance 
verification. 

The DPS hardware was of modular design to 
permit sizing to meet requirements of the proc- 
essing tasks associated with each deployed site. 
The design was standardized so that any number 
of processors could be combined with any number 
of storage units to meet the requirements of a 
given site. 


Most equipment was designed, developed, and 
manufactured by Bell Laboratories and Western 
Electric. Lockheed Electronics produced core 
memory systems for program and variable 
stores. 


Software 


The basic tactical functions of the SENTINEL 
System were embodied in the software programs 
which would drive the data processors at each 
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site. These tactical functions were to be imple- 
mented in three generic weapons processes — 
one each for the PAR, MSR, and BMDC, Ver- 
sions of these processes would be used at the 
various sites, with each version site-unique and 
capable of operating only in the DPS at the site 


for which it was designed.?4 


The Weapons Process requirements were 
specified in Data Processing System Performance 
Requirements (DPSPRs), prepared as a result 
of system engineering and analysis of overall 
system objectives. These documents specified 
the fundamental concepts, functional require- 
ments, and constraints for SENTINEL System 
deployment. In addition, requirements for 
software-driven equipment tests and readiness 
verification were included. 


The plan for development of SENTINEL weap- 
ons processes as well as other software required 
at the tactical sites included development of 
tactical support software.353* In this category 
were: 

e Program Preparation Facilities — includ- 


ing all tools necessary to assemble, 
maintain, and construct a process 


e Program Execution Facilities — including 
the basic DPS management facility andthe 
Tactical Operating System 


e DPS Test and Maintenance Facilities — 
including provisions for maintenance of 
DPS hardware and diagnosis of faults. 


Software development also included special 
installation software packages for use during in- 
stallation and testing of SENTINEL site hardware. 
Three types of installation software were to be 
developed: (1) the DPS Installation Test Facility, 
(2) the PAR Installation Process, and (3) the 
MSR Installation Process. 


In addition, software processes were devel- 
oped for the Meck Test System. The initial 
software provided for Meck was much like the 
DPS and MSR Installation Processes. A soft- 
ware process, referred to as M-1, was an 
early prototype for the tactical MSR Weapons 
Process and provided the method for exercising 
the MSR, MSDP, and missile subsystems. 


Testing 


Major testing for the SENTINEL System was 
conducted with the Meck Test System which 
consisted of the MSR, MSDP, SPARTAN, and 
SPRINT subsystems.? The purpose of the Meck 
test program was to: 

e Exercise and evaluate all elements of the 

subsystems installed 


e Achieve SPRINT and SPARTAN intercepts 
against high-performance targets of known 
and controlled characteristics 


e Permit study and evaluation of man's role 
in augmenting system responses 


e Gather data applicable to the continuing de- 

sign effort. 

The test plan was directed toward evaluating 
those functions related specifically to SENTINEL 
deployment. This plan involved several phases 
‘of system testing at Meck Island. The M-0 phase 
used sets of comparatively small software pack- 
ages to facilitate checkout of the radar, data 
processor, missile subsystems, and the inter- 
faces between subsystems. The M~-1 phase pro- 
vided initial tactical functional capabilities re~ 
quired in the area defense role, including the 
first MSR-guided SPARTAN and SPRINT inter- 
cepts. Subsequent phases were to be designed 
with the functional capability required to test 
against the growth threat and to evaluate hard- 
site defense. 


SUMMARY AND CONCLUSIONS 


In the total story of ABM development, the 
SENTINEL System is but one brief chapter. Al- 
though not actually deployed, SENTINEL was sig- 
nificant in that it was the first ABM system on 
which an affirmative decision to deploy was made. 
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This decision initiated development and other re- 
lated activities not addressed as specifically, or 
in as much depth, for earlier systems. Not sur- 
prisingly, some of these activities turned up im- 
portant problems that required significant atten- 
tion and therefore became important conclusions 
in the planning for SAFEGUARD. 


Because the SENTINEL System evolved into 
the SAFEGUARD System, rather arbitrary judg- 
ments were required to identify the conclusions, 
or lessons learned, from SENTINEL. The follow- 
ing list emphasizes those items which relate only 
to SENTINEL, or which were clearly highlighted 
before the transformation to SAFEGUARD. 


e It became very clear that development, 
testing, and integration of the large and 
complex software programs required for 
the system seriously affected successful, . 
on-schedule completion of the project. 
This led to an intensive effort to expedite 
the software development for SAFEGUARD. 
The technical and management procedures 
which resulted are described in Chapter 4, 
SAFEGUARD System, and Part III, Man- 
agement and Overall Approach. 


e Providing adequate confidence that the sys- 
tem was operational emerged as a difficult 
task. The design of an extensive built-in 
System Readiness Verification subsystem 
therefore became an important part of the 
system design. 


e Specification of requirements for positive 
nuclear control having a very short reaction 
time necessitated a complex interface with 
the various organizations involved. 


e A complex Command and Control System 
was required to internet the elements of 
the SENTINEL deployment. The unique 
requirements of SENTINEL made the de- 
sign of such a system difficult. 


e An organization of Configuration Control 
Boards was established to provide a Con- 
figuration Management System to control 
the requirements for the many elements 
of the SENTINEL System. 
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SAFEGUARD is an ABM system designed to 
protect U.S. Minuteman ICBM bases from attacks 
by enemy ballistic missiles. Development of the 
SAFEGUARD System began with a redirection of 
the SENTINEL program in March 1969. Its de- 
ployment plan called for a number of sites to be 
constructed primarily in the western part of the 
United States. As a result of the Strategic Arms 
Limitation Treaty (SALT) and related program 
decisions, actual deployment was subsequently 
limited to a single complex in North Dakota and 
a system command center in Colorado. 


The initial SAFEGUARD plan called for up to 
twelve sites deployed in two phases. The first 
phase, for which authorization was originally 
granted, provided Minuteman defense at Grand 
Forks Air Force Base (AFB), North Dakota, and 
at Malmstrom AFB, Montana, together with a 
Ballistic Missile Defense Center (BMDC) at 
Cheyenne Mt., Colorado. The second phase 
would have added Minuteman defense at Whiteman 
AFB, Missouri, and at Warren AFB, Wyoming, 
as well as defense of the National Command 
Authority (NCA) in Washington, D.C. This phase 
also retained the option to add additional sites to 
protect Strategic Air Command (SAC) bases and 
population centers. In March 1971, approval was 
granted to proceed with the installation at White~ 
man and to plan for the Warren site. Whiteman 
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was designated as the Fire Control Center (FCC) 
and Malmstrom as the Alternate Fire Control 
Center. The FCC was an intermediate command 
center reporting to the BMDC. A year later, 
however, authorization for the Whiteman site 
was rescinded and Malmstrom was designated as 
the FCC. 


In accordance with the terms of the Strategic 
Arms Limitation Treaty of June 1972, and a sub- 
sequent Congressional decision not to authorize 
the permitted deployment in the Washington, D.C. 
area, the SAFEGUARD System was further re- 
duced to provide Minuteman defense only at 
Grand Forks AFB. Thus, the current deployment 
consists of a Perimeter Acquisition Radar (PAR) 
and a Missile Direction Center (MDC) in North 
Dakota, both under overall command of the 
BMDC in Colorado. Included in the MDC are a 
Missile Site Radar (MSR) and associated SPRINT 
and SPARTAN missile farms. This deployment 
is depicted in Figure 4-1 and is aimed at pro- 
viding a number of defense capabilities,** 


The three types of sites in the SAFEGUARD 
System are interconnected by communications 
links. The PAR site uses a single-face, phased- 
array radar to provide early detection and target 
trajectory data on threatening ICBMs. Functions 
of this site include long-range surveillance, de- 
tection and selection of threatening objects, and 
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Figure 4-1. SAFEGUARD ABM System 


ICBM threat tracking for SPARTAN intercept. 
This last capability significantly increases the 
long-range SPARTAN field-of-fire. The PAR 
site does not perform missile guidance, but in- 
stead, transmits trajectory and target classifica- 
tion data over the tactical communication links to 
the MDC. The MDC uses this information to- 
gether with data from its own multi-faced, 
phased-array Missile Site Radar. This site pro- 
vides additional surveillance and target tracking 
as well as track and guidance for SPRINT and 
SPARTAN missiles. Both PAR and MDC sites 
report to the BMDC, which provides a command 
interface with other military systems and ameans 
of disseminating command directives and controls. 
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The PAR and MSR are controlled through 
digital commands issued by collocated Data 
Processing Systems (DPSs). These commands 
are used to manage such radar functions as beam 
pointing, frequency selection, receiver gating, 
thresholding, etc. In addition, application pro- 
grams in the PAR and MSR Data Processors 
(PARDP and MSRDP) manage the major system 
functions of surveillance, tracking, target clas- 
sification, radar testing, intersite communica- 
tion, and command/control/display. At the MDC, 
other programs support engagement management 
and missile guidance. The BMDC DPS primarily 
performs command, control, and display 
functions. 
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MAJOR SAFEGUARD ELEMENTS 
Perimeter Acquisition Radar 


The Perimeter Acquisition Radar performs 
long-range surveillance, detection, and tracking 
of ICBMs for SPARTAN missile intercept.’* As 
an auxiliary function, it can provide track data 
on selected satellites of interest. To withstand 
nuclear blasts, the radar equipment is mounted 
in a reinforced concrete structure which is 
shielded against nuclear electromagnetic radia- 
tion. The front face of the building supports an 
array of 6888 antenna elements (see Figure 4-2). 


At periodic intervals, the PAR searches the 
volume of space within a large solid angle in 
front of the array face, It can detect small tar- 
gets in a typical ballistic missile complex at 
large distances with a high probability of detec- 
tion. The radar operating frequency can be 
changed and the antenna beam-pointing direction 
can be switched between points in space and 





between multiple transmissions in the same radar 
interval. 

The PAR transmitter consists of high-power 
Traveling Wave Tubes (TWTs) whose combined 
total peak radiated power is in the multimega - 
watt range. Target returns are amplified by 
low-noise transistor amplifiers which are an 
integral part of the phase-steered corporate-fed 
array. Further details on the PAR are given in 
Chapter 8. 


Missile Site Radar 

The Missile Site Radar is a four-face, single- 
beam phased-array radar operating in S-band. 
Its function is to acquire and track incoming bal- 
listic missiles and to launch and guide SPRINT 
and SPARTAN missiles for intercept.’""" The 
MSR can also launch and guide SPARTAN mis- 
siles for intercept using PAR target data, 


Figure 4-2. PAR Building 


To withstand nuclear effects, the radar equip- 
ment is housed in a reinforced concrete structure 
shielded against nuclear electromagnetic radia- 
tion.” A large portion of the building is below 
ground with an above-ground turret containing 
the four phased arrays to provide hemispheric 
coverage (see Figure 4-3). Each of the four 
arrays consists of 5001 elements used for both 
transmission and reception. 


The MSR scans the complete hemisphere and 
can detect targets of small cross section at 
ranges of several hundred nautical miles," 

The antenna beam pointing direction and opera- 
ting frequency can be switched between points in 
space between transmissions. Separate transmit 
and receive feedhorns are used behind each MSR 
space-fed array. 


The MSR transmitter final amplifier has two 
high-power klystrons operating in parallel, each 


with its own power supply. This permits opera- 
tion at half power, should one unit fail. The 
transmitter output power is in the megawatt 
range at high duty cycle. Target returns are 
amplified by a cooled parametric amplifier be-~ 
fore dechirping to achieve the required sensi- 
tivity. Further information on the design and 
performance of the MSR is given in Chapter 7, 


SPRINT Subsystem 


The SPRINT Subsystem consists of high- 
performance, ground-radar-controlled, nuclear- 
armed interceptor missiles and associated sup- 
port equipment. The missiles are emplaced and 
ready for launch from underground cells which, 
together with their support equipment, are de- 
ployed in launch areas, or farms, at the MSR 
collocated site (Figure 4-4) and at farms remote 
from the MSR.. 





Figure 4-3. MSR Site 
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Figure 4-4, SPRINT Cell with MSR in Background 


The SPRINT interceptor missile is designed 
to provide fast reaction-time in reaching endo- 
atmospheric intercept points.’ At launch, the 
missile is ejected from its underground cell and 
its first stage ignites automatically. A pitchover 
maneuver is initiated prior to acquisition and 
track by the MSR. A 'missile model" in the 
computer tells the radar where to look on the 
planned trajectory so that acquisition can be 
made as soon as a Clear transmission path is 
available. After first-stage burnout, the second 
stage is ignited by ground command. The second 
stage burns for a short interval during which final 
corrective steeringorders are issued andthe mis- 
sile attains the altitude necessary for intercept. 
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In-flight fratricide related to launch station 
spacing is a limiting constraint on the rate-of- 
fire. The launch equipment is capable of accept- 
ing launch orders and initiating the launch 
sequence in a very short interval after receipt of 
a preparation order. This interval includes the 
time alloted for tests requested either locally or 
by radar command and can be reduced somewhat 
if these tests are not conducted. Refer to 
Chapter 9 for further details on SPRINT. 


SPARTAN Subsystem 


The SPARTAN Subsystem consists of high- 
performance, ground-radar-controlled, nuclear- 
armed interceptor missiles and associated 


support equipment. The missiles are emplaced 
and ready for launch from underground cells de- 
ployed in a collocated farm at the MDC site. 
Each cell ‘is equipped with environmental control 
equipment, as well as testing, monitoring, and 
exercising facilities. 


The SPARTAN interceptor missile, on com- 
mand from the MDC Data Processor, is launched 
from its underground cell at an angle of 5 degrees 
from the vertical. After launch, the missile fol- 
lows a radar-controlled flight plan using three 
solid-propellant-powered stages and two in- 
flight separations. 


Aiter first-stage boost and burnout, the 
second stage is ignited automatically and booster 
separation is achieved by second-stage thrust 
forces. Second-stage control and maneuver- 
ability are provided by the second-stage fixed 
fins and the third-stage deflectable fins. After 
second-stage burnout, the missile exits the atmo- 
sphere in the glide mode. For intercept to occur, 
the burned-out second stage must be separated 
from the third-stage warhead section. Separa- 
tion is achieved by skin-cutting ordnance shortly 
after third-stage ignition. Both ignition and 
separation events are accomplished by ground 
command and occur in the exoatmosphere region. 
Third-stage exoatmospheric control is accom- 
plished by directing the exhaust from the third- 
stage motor through nozzles which are an integral 
part of the third-stage fins. Finally, the nuclear 
warhead is spin-stabilized during the latter por- 
tion of third-stage burn. 


The SPARTAN launch equipment consists of 
the launch and test equipment and the launch re- 
radiation antenna, The launch equipment pro- 
vides for testing launch station hardware and 
missiles under control of the MDC Data Proces- 
sor. This testing detects any faulty or unsafe 
condition to ensure that the subsystem is in a 
battle-ready state permitting missiles to be 
launched in rapid-fire sequence. Refer to 
Chapter 10 for further details on SPARTAN. 





Data Processing System 


The SAFEGUARD Data Processing System 
(DPS) design was dominated by requirements for ean 
high performance and high availability and re- 
liability.*-8 High performance requirements are 
dictated by the nature of the DPS's primary job: “4 
managing system resources and controlling a 
large radar tracking and missile guidance system , 
in real time. After radar returns are processed, Ae 
new commands must be generated and transmitted 
to the radar every few milliseconds on a fixed 
schedule, This results inpeak processor through~ 
put of 10 million instructions per second and peak 
transmission rates to service the radar and od 
other peripheral devices of 200 megabits per 
second, !8-21 , 
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The DPS equipment at a Missile Direction 
Center is shown in Figure 4-5. The Central 
Logic and Control (CLC) is the multiprocessing 
computer used to drive the radar and the other 
peripherals shown. Under software control, the 
CLC can be configured into two separate parti- 
tions of arbitrary size, each capable of operating 
as an independent computing system. Tactical 
application programs execute on the larger or 
"green" partition. Exercise drivers for the Sink 
application programs and independent support- 
activity programs execute on the smaller or 
"amber" partition, which also provides a oa 
reserve of spare equipment. 





The CLC can be configured with up to ten rod 
processors2? Single-processor throughput of MS 
about 1.5 million instructions per second is 
achieved by a combination of design techniques 
that include instruction execution overlap and 
use of high-speed arithmetic algorithms .19.20 
Every processor has access to each of several 
read-only instruction memories called program 
stores, and several read-write memories called 
variable stores. These stores have a memory- 
cycle time of 500 nanoseconds and a double-word 
size of 64 bits to provide a memory bandwidth in 
excess of that required for maximum performance 
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Figure 4-5. Data Processing System Equipment 


of a single processor. All data transfers be- e Intersite Data Transmission Controllers - 
s A provide transfers of digital data via data 

tween the CLC and its peripherals are controlled links between sites BF 

by an Input/Output Controller (IOC), thereby al- 


e@ Exercise Support Units - required in sys- 
lowing processing and I/O tasks to be accom- tem exercises to provide an interface re 
: 21 tween the simulated threat running in the 
plished simultaneously. amber part of a partitioned DPS and the 
Table 4-1 shows the CLC configurations, both ate ograms running in the green 
green and amber, in the SAFEGUARD System. @ Command and Control Display Subsystem - 
provides the man-machine interface for 


pe veralimna jor mabey ete ms perience rab tothe monitoring and directing tactical operations 


CLC are shown in Figure 4-5. These include: through Cathode Ray Tube (CRT) displays, 
consoles, teletypewriters, and wall : 
e Radar Interface Controller - provides the displays,2/-31 


primary interface between the IOC and the 
radar for exchange of control and data 
words. This unit accepts formatted binary 
words from the CLC and distributes data 
to the appropriate radar subsystems. 

¢ Missile Launch Subsystems - convert CL @ Maintenance and Diagnostic Subsystem 
commands into control signals for the ook: (M&DSS) - provides a centralized facility 
located and remote missile farms; this equip- for testing and maintaining di eta) saniwere 
ment also receives missile status informa- to ensure the availability and readiness of 


tion for encoding and transfer to the CLC. the DPS. 7-35 The M&DSS uses unique 


e Recording Subsystem - contains the stand- 
ard computer peripheral devices: magnetic 
tape transports, disk memory units, line 
printers, and card reader. 
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Table 4-1 
CLC Se ae 


ee 


Processor Units 
: 
5 
1 
1 


Program Stores 
Variable Stores 
I0Cs 
Timing & Status 
dedicated hardware to conduct non-real- 
time, programmed diagnostic tests on the 
DPS equipment through an independent data 
bus connected to each digital unit. The 
M&DSS also supports initialization of the 
DPS hardware and assists in automatic 
reconfiguration and recovery of this hard- 
ware should it be necessary during the 
tactical mission. 






For more information on the DPS equipment, 
refer to Chapter 11. 


SOFTWARE DEVELOPMENT 
Development Cycle 


The SAFEGUARD development benefited sub- 
stantially from prior work on the R&D prototype 
called the Meck Test Facility. This effort pro- 
vided an early demonstration of critical ABM 
concepts and also collected data needed for sub- 
sequent design and evaluation. The many lessons 
learned were applied directly to the SAFEGUARD 
program. 


The software development cycle involved a 
number of distinct phases. These phases over- 
lapped, since the general approach used required 
integration of a basic working system with in- 
creasingly more complex capabilities.** This in- 
tegration was performed at a separate test facil- 
ity, the Tactical Software Control Site (TSCS), 
using special system exerciser arrangements, 


The separate phases of the development cycle 
were as follows: 


@ Requirements Generation - initial system 
requirements were determined, established, 
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Green Sa 
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negotiated, documented, and rigorously 
controlled. 


e Software Design - in process design, sys- 
tem requirements were translated into a 
software architecture which defined global 
structures, tasks, task priorities, and 
task timing requirements for the data proc- 
essing environment. In program design, 
the local data base, algorithms, and con- 
trol structure for individual tasks were 
determined. 


e Coding and Unit Testing - codes were 
written, compiled, and checked at the unit 
or task level using a simulator, drivers, 
and standard debugging techniques. 


e Process and Functional Integration - facili- 
ties of TSCS were used to combine blocks 
of new debugged unit code into processes 
of increasing functional capability. When 
the tactical software attained a predefined 
level of capability, it was sent to site for 
final integration. 

Activities at site were similar to those at the 
TSCS. However, at site the entire complement 
of peripheral hardware was available for integra- 
tion with the system. The final phase of system 
development involved system testing, in which 
the PAR, MDC, and BMDC sites were "netted" 
to achieve coordinated operation of the entire 
system. After this, formal acceptance tests 


were run at Site. 


During all phases of system development, 
evaluation played a strong role. A separate de- 
partment was responsible for evaluating system 
requirements, implementation algorithms, and 
Feedback 


resulted in frequent changes and refinements 


prototype and system test results. 


in many areas, 
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In the following paragraphs, the software de- 
velopment activities outlined above are discussed 
more fully. 


Meck Test Facility 


The Meck Test Facility consisted of a proto- 
type MSR, SPRINT and SPARTAN missile sub- 
systems, anda DPS. During the R&D phase, 
ABM system requirements were constantly 
changing; thus it was decided to implement a 
series of test processes on Meck, each with in- 
creasing complexity and more stressing system 
objectives. 


The first process, M-0, was designed to test 
the radar and missile hardware subsystems. 
The next process, M-1, tested both SPRINT and 
SPARTAN intercept capability in a light-threat 
environment. The final process, M-2, verified 
SAFEGUARD tactical algorithms for missile 
guidance, as well as radar surveillance and track- 
ing functions. This inclued remote launches of 
SPRINT missiles from Dleginni Island. The test- 
ing took place from early 1969 through 1974. 


A total of 882, 000 program instructions were 
written for the Meck Test Facility, but only 
255,000 instructions were included in the three 
test processes. The remainder were needed for 
hardware installation and maintenance programs 
(137,000 instructions) and support software, 
suchas assemblers, process construction, simu- 
lation packages, etc. (490, 000 instructions), 


In addition to the planned testing and verifica- 
tion, the Meck effort made other contributions to 
SAFEGUARD. Many of the techniques, proce- 
dures, and practices developed were later to be 
used in the SAFEGUARD software development. 
These were in many diverse areas, such as 
operating system and process design, software 
configuration control, and real-time debugging 
aids, to name a few. 


TSCS and System Exerciser 


To develop and test SAFEGUARD software and 
to support system deployment, the Tactical 


Software Control Site was established at Madison, 
New Jersey. This test facility contains the PAR 
and MDC data processing equipment and portions 
of the analog hardware that interface with the 
missiles and radars at site. The TSCS also in- 
cludes office space for major elements of the 
software development organization, consisting of 
designers, programmers, and test teams, as 
well as many other support personnel. 


The basic requirement of the TSCS was to re- 
produce accurately the software environment 
found at site, In short, its objectives were 
to: 

e Verify performance of tactical software in 

its operational environment 


e Test software in conjunction with the design 
organization 


e Reduce development time through compre- 
hensive testing prior to shipment to site 


e Support deployment activities by providing 
a centralized facility to aid in solving 
problems encountered at site. 


The TSCS was required to have a representa~ 
tive complement of DPS hardware for both the 
PAR and the MDC. This meant two distinct DPS 
configurations, each sized in accordance with 
tactical requirements (see Figure 4-6). Fur- 
thermore, each configuration had to replicate the 
interfaces between computer and peripherals, 
and the operation of peripherals to the extent 
necessary for tactical-like responses. In addi- 
tion, the capability to net the PAR and MDC was 
required for system testing. 


The tactical equipment at TSCS was used al-" 
most exclusively to test and integrate the 
SAFEGUARD operating system, application soft- 
ware, and installation and maintenance software. 
The support functions needed to develop, control, 
and analyze tactical software were relegated to 
general purpose computers.” An IBM System 
370 was installed at TSCS and off-premises 
access to a HIS 635 was provided. 


A system exerciser was developed to test 
tactical software in the SAFEGUARD equipment 
at TSCS. A separate exerciser was provided for 


TACTICAL SOFTWARE 
PREPARATION 
ENVIRONMENT 






COMPUTATION CENTER 


IBM SYSTEM 370 
AND RELATED 
SUPPORT 
FACILITIES 







DATA 
PROCESSING 
EQUIPMENT 


DATA 
PROCESSING 
EQUIPMENT 


MDC TSCS CONFIGURATION 


PAR TSCS CONFIGURATION 


TACTICAL SOFTWARE 
S———-_ EXECUTION ENVIRONMENT ————-~,_ 






MSR 
INTERFACE 
EQUIPMENT 











MISSILE 
INTERFACE 
EQUIPMENT 












SYSTEM 
EXERCISER 
EQUIPMENT 













SYSTEM 
EXERCISER 
EQUIPMENT 














PAR 
INTERFACE 
EQUIPMENT 





Figure 4-6, Tactical Software Control Site Functions 


each configuration (PAR and MDC) for individual 
testing and for joint testing of the two systems in 
netted operation. 38:38 These exercisers are used 
now in the deployed system for site and system 
readiness verification. 


In designing the system exerciser, care was 
taken to devise a method that would realistically 
produce an environment similar to the actual 
tactical conditions found at site. Two special 
hardware aspects provided this capability. First 
and most important, the PAR and MDC configura- 
tions were each configured into two separate 
partitions as shown in Figure 4-7, The larger, 
or green partition, contained the tactical appli- 
cation software as it would be used in an actual 
engagement; the smaller, or amber partition, con- 
tained the system exerciser software. Second, 
special exercise support hardware was developed: 
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an Exercise Control Unit (ECU) and a Radar 
Return Generator (RRG). 


During a system exercise, the amber partition 
generates radar returns representing a pre- 
selected threat. 
ECU to the RRG for conversion to analog form 
and injection into the radar receiver of the green 
The tactical (or green) partition re- 


These returns are sent via the 


partition. 
sponds as in a real engagement, issuing radar 
orders, missile commands, and intersite com- 
munications. These are sent via the ECU to the 
amber partition where they control simulated 
missile responses. The ECU also appropriately 
routes these responses and intersite communi- 
cations from the amber partition to the missile 
ground equipment and tactical communications 
links in the green partition. 
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Figure 4-7, Functional Configuration for System Exercise 


When the system exerciser is used in the simulated threat on tape. These tapes then are 
netted mode, the tactical communication between used during an exercise by the exerciser soft- 
the PAR and MDC is not interruptedfor any simu- . ware in the amber partition to generate the 
lated response, but is allowed to flow normally Simulated responses. * 
on one circuit of the split link. The other circuit 
is used for communication between the PAR and Requirements 


MRO SReteisets: The Data Processing System Performance 


The system exerciser has sufficient traffic Requirements (DPSPRs) are a set of documents 
capacity to test tactical hardware and software that define the requirements of SAFEGUARD 
at the required design level. Yet, the amber tactical software for the PAR, MDC, BMDC, and 
hardware requirements were kept to a minimum system exerciser. 38-‘? Requirements were gen- 
by performing as much simulation as possible erated by the system engineering organization in 
prior to conducting a real-time exercise. A accordance with overall system objectives. 


program called the SAFEGUARD Threat Action 
Generator (STAG) was developed to generate 


target, defensive missile, and intersite message *For additional information see SAFEGUARD 
information (for local exercises) in a scenario Data Processing System: Process-System Test- 
defined by an input deck. STAG is run in non- 5 ter PF Meborald. Bell System fe oe i 


real-time on the IBM System 370 and records the Journal - Special Supplement (1975). 


The primary objective of the DPSPRs was to 
specify required functional performance in suf- 
ficient detail to permit development of software 
by the designers, yet not limit design freedom. 
A second objective was to state functionally how 
the system was to operate in its different defense 
modes. 


Changes in requirements were made through 
the course of development as a result of feedback 
from the software development organization, the 
SAFEGUARD System Tests conducted at Kwajalein 
and Grand Forks, system evaluation studies, and 
from detailed review by the Army SAFEGUARD 
System Command (SAFSCOM). Later on, formal 
change-control procedures were instituted on 
these documents to ensure an up-to-date system 
definition of SAFEGUARD performance and to 
control the final software products. 


Final system testing and acceptance require- 
ments generated by the system engineering 
organization were based on the DPSPRs. 


Software Design 


The collection of application software used to 
drive the DPS is called the application process 
and is built from basic computing units, called 
tasks, which are single routines with or without 
subroutines. The operating system, considered 
to be part of the process, schedules tasks from 
a predetermined, priority-ordered task list for 
execution on the next available processor.*!:*? 
Once in execution, a task is not interrupted be- 
fore completion except for error conditions.‘ 


Process design is the definition of overall 
software structure including task assignment and 
global data base design. The objective of process 
design is to meet system requirements with a 
minimum-cost DPS configuration. This activity 
was complemented by program design which in- 
volved developing the algorithms, internal data 
base, and control structure necessary to imple- 
ment the function defined for a task. The soft- 
ware design was documented in process design 
specifications and process workbooks. Between 
this detailed level of documentation and the 


DPSPRs, some application process organizations 
also produced intermediate-level software func- 
tional design requirements. 


In many areas, various levels of simulation 
were used to validate the design. In some cases, 
a few selected equations were implemented on a 
time-sharing system for a quick exploration of 
correctness and adequacy. In others, a subset 
of the real-time computer program, complete 
with its interface structures, was simulated. In 
the PAR development, the intermediate-level 
functional design requirements, together with 
radar, threat, and environmental considerations, 
were modeled and simulated to study expected 
system performance. 


The size of individual programs and the time 
required for their execution were two major 


‘parameters that were carefully controlled. Ini- 


tial sizing and timing estimates were made early 
in development based on past experience with 
similar programs. Throughout the course of 
further development, sizing and timing estimates 
were tracked on a monthly basis. 


It was found essential to initiate design of the 
data recording and reduction system early in the 
development cycle. An attempt was made to de~ 
fine the data to be recorded tor each computing 
function and to design the data base with the ulti- 
mate use of the recorded data kept in mind. 


Coding and Unit Testing 


Most SAFEGUARD software was written in 
CENTRAN, an extensible intermediate-level 
language resembling a subset of PL/1.“ 
CENTRAN is a macro-based language built on 
SNX, the assembly language for the CLC. As 
such, CENTRAN provides many of the advantages 
of a high-level language but can be interspersed 
with assembly language statements and system 
macros as necessary. CENTRAN generates 
efficient code and was adopted-as the project 
standard. 


A projeci-wide attempt was made to include 
defensive programming techniques during the 








coding period. Particular attention was given 

to computations that potentially could cause in- 
terrupts which, in turn, would result in task 
termination. Detection and error recovery codes 
were then added. Another project-wide technique 
involved enforcing adequate source-code docu- 
mentation by requiring well-commented program 
listings. This proved particularly effective 

later on in isolating programming errors that 
were detected during the integration phase. 


All programming organizations responsible 
for a functional area of the application software 
held design reviews for the total project. These 
reviews not only helped to educate test and inte- 
gration personnel, but sometimes uncovered 
subtle design flaws. Some programming groups 
used structured programming. These techniques 
led to an orderly top-down approach in the de- 
tailed programming design and coding. In such 
instances, a substantial saving, both in variable 
store and in computing time, was often achieved. 


Once the coding of individual software units 
was complete, two stages of testing were under- 
taken. Units assigned to individual program- 
mers - generally entities of code ranging from 
100 to approximately 1000 machine instructions - 
were individually tested. The purpose of this 
unit testing was to test the logic paths within a 
unit. To support this activity, a number of 
special drivers were developed to allow indivi- 
dual units to be interfaced with the data sets 
needed in their operation. These drivers sequen- 
tially initialized the data sets to produce the en- 
vironment necessary to execute one logic path 
after another. Element testing was the second 
stage of testing. Program units comprising a 
major functional element of the process were 
tested together using special software ''stubs" in 
place of the other major functions. These tests 
were primarily functional in nature. A series 
of tests was defined that would exercise all major 
functional requirements given in the system re- 
quirements and design specifications. 


All software preparation and most of the unit 
and element testing was performed using 


commercial computers. This was primarily 
because time on the TSCS test facility was too 
limited to support such extensive activity. How- 
ever, a decided advantage accrued from this 
approach since a number of testing and debugging 
tools were already available on the commercial 
machines. Others were developed specifically 
for SAFEGUARD in high-level languages such as 
FORTRAN and PL/1. One such tool was the 
simulator called STACS (SAFEGUARD Tactical 
Computer Simulator) which provided the primary 
unit and element testing vehicle.45 STACS fully 
Simulates, on the IBM System 370, a single CLC 
processor and most of the conventional CLC 
peripheral units. It also simulates many of the 
operating system capabilities designed for the 
CLC. Special test drivers were designed to in- 
terface with STACS, providing universal testbeds. 
In addition, a variety of debugging aids were in- 
cluded in STACS to allow exhaustive testing of 
program units. Such debugging aids range from 
simple snaps and traces to simulation of error 
response’ and the ability to modify or patch a unit. 


Configuration Management was an important 
aspect in development of the software product.'*-* 
Methods were developed to identify, control, 
track, and audit the numerous versions of the 
programming units to be released for process 
integration. These methods included rigid con- 
trol of the patches required to correct the coding 
problems discovered during integration .'?:49 
Central to this activity was a disc-based library 
system which was an IBM proprietary product. 
This system offered many of the features neces- 
sary to sustain a large development effort. For 
example, it included an editor for changing source 
lines, a means of temporarily changing source 
for testing, and amechanism to facilitate delivery 
of debugging code. Perhaps its most significant 
contribution was the procedural discipline it uni- 
formly forced on all SAFEGUARD programmers. 


Other procedures were developed td control 
Trouble 


Reports (TRs) were required to document any 
problems occurring during testing. Corresponding 


all patches made to delivered software. 


Correction Reports (CRs) described the approach 
used in correcting the trouble via a patch or 
source change. A large number of support soft- 
ware packages were developed to assist in these 
configuration management procedures, and in- 
cluded programs ranging from the building of 
patch files for a process to the identification and 
reporting of status on TRs and CRs.!#49° 


Process and Functional integration 


Following unit and element testing, collections 
of functions were combined and tested on the PAR 
and MDC DPS configurations at TSCS. For ex- 
ample, the basic control programs for the MDC 
were first merged with the operating system, 
and the ability to load, initialize, and cycle was 
established. Then, software for the radar loop 
was added, i.e., radar management, search, 
and track programs. 


Ability to search and track was first estab- 
lished at low traffic levels, while the radar hard- 
ware was simulated by software drivers. After 
basic operation was established for the software, 
the radar hardware was introduced into the testing 
loop. In parallel with this activity, application 
programs supporting intersite communications 
and command and control were tested in a separ- 
ate configuration at TSCS. Similarly, both battle 
planning and missile guidance software were 
tested in separate software environments. UIlti- 
mately, these programs were merged into a 
single MDC application process and the complexity 
of the test cases was systematically increased. 


This integration was done separately for the 
PAR and MDC with the effort planned, as seen 
above, so that a number of parallel activities 
could be carried out by independent integration 
teams. Such an incremental approach allowed 
for integration of increasingly more complex 
capabilities into the software, building from a 
simple nucleus of code and culminating in a full 
application process for each site. 


Early in this integration, drivers were de- 
veloped to assist in the first steps. These early 
efforts, referred to as process integration, were 


devoted mainly to software considerations such 
as basic cycling, sanity, and interface testing 
between major software blocks. Later, when the 
system exerciser was available, it was used ex- 
clusively to drive and stress the application proc- 
esses under various conditions and loads. This 
testing also covered the radar hardware at TSCS 
and was planned to include specific functions 
given in the requirements. This functional inte- 
gration testing culminated in demonstrating 
satisfactory performance in both the local and 
netted modes of the large scenarios planned for 
eventual system testing at site. Literally thou- 
sands of individual test cases were documented, 
including the success criteria, and then run in 


’ support of the overall process and functional 


integration phases. 


A number of support software facilities were 
crucial in building and testing these large appli- 
cation processes. (See Figure 4-8.) CENTRAN 
and SNX, like most compilers and assemblers, 
produced relocatable object code. A program 
was developed to allocate CLC memory, build 
the control tables needed by the operating system, 
perform binding functions, structure the over- 
lays, and perform a host of related services, 
This program, called the Execution Preparation 
Facility (XPF), operated on the IBM System370. 
Similarly, most testing of software units and 
elements produced by XPF was performed by 
STACS on the IBM System 370. 


Another software package, called DEBUG, 
provided software debugging aids for the CLC 
and proved invaluable early in process integra- 
tion 52. DEBUG's capabilities included many 
of the same aids provided on the support com- 
puters by such facilities as STACS. Although 
DEBUG contained some multiprocessor capa- 
bilities, its design was oriented more toward a 
single processor, non-real-time environment. 
Further extension of debugging aids on the CLC 
resulted in the development of DARTS (Debug- 
ging Aids for Real-Time Systems). This soft- 
ware provided full multiprocessor, real-time 
capabilities with minimum perturbation on the 
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timing and operation of the application program 
under test. An array of features was made 
available, including the ability to simulate 
manual inputs in real time. 


The CLC Monitor was developed to further 
isolate the effects of running debugging tools on 
the application process being tested. This 
monitor is an external hardware monitor which 
includes its own memory, extensive logic to 
count and filter data, and two tape units. It was 
used primarily to validate that process perform- 
ance was consistent with design. Troubles, such 
as heavily-loaded time frames and long-running 
tasks, were analyzed and design changes were 
made when necessary to provide a more balanced 
system. 


Detailed analysis of functional integration 
tests was facilitated by designing the real-time 
recording functions as an integral part of the 
application and exercise software. Recorded 
data was reduced and analyzed primarily off-line 
on the IBM System 370 using the SAFEGUARD 
Data Reduction System, although summary in- 
formation was available on-line.*** 


Site Integration and System Testing 


The TSCS and site integration phases signifi- 
cantly overlapped in time.** As tests were com- 
pleted at TSCS, software updates in the form of _ 
patches and data packages relating to performance 
of the tests were sent to site. These packages 
included test specifications, exerciser tapes, 
test results, and reports which itemized any 
known problems not yet corrected. Site integra- 
tion then consisted of testing the application soft- 
ware against the full complement of SAFEGUARD 
hardware using a subset of TSCS tests and special 
site-oriented tests such as radar-calibration and 
satellite-tracking tests. 


Finally, system testing was carried out at site. 
This involved a comprehensive series of accept- 
ance tests which demonstrated system capability 
consistent with requirements and represented the 
final level of product testing prior to delivery .5-# 
During system testing, it was not possible to 
exhaustively test all tactical threat environments. 
Rather, these acceptance tests, or System Tech- 
nical Verification Tests (STVTs) as they were 
called, were defined at the design-traffic level 


for each of the various system operating modes. 
A series of tests was designed for each mode, at 
first simulating all communications with other 
sites, then netting pairs of sites, and finally net- 
ting the entire system. 


The stress level was reduced in early testing 
by selecting subsets of the STVT environments 
and by running buildup tests at these lower stress 
levels before increasing the traffic load. Once 
this was accomplished, the "test chain" was 
continued by physically internetting the sites in 
stages until the total system was operating at 
design-traffic levels. This approach, in which 
all tests.in the chain support the STVTs, greatly 
simplified the problems of integrating a dynamic 
system. 


SAFEGUARD OPERATION AND MAINTENANCE 
Operational Overview 


The size and duration of the SAFEGUARD de- 
velopment effort were large indeed. Table 4-2 
shows the number of machine instructions for the 
- major software components, Real-time software, 
consisting of MDC and PAR application programs 
with their exercisers, the BMDC application pro- 
gram, and the CLC operating system, contained 
a total of 735, 000 instructions.*-” Support soft- 
ware, such as compilers and simulators, which 
executed on commercial computers, amounted to 
580, 000 statements, some in assembly language 
and some in PL/1 and FORTRAN. Installation 
and maintenance software for the data processing 
system and the radars totalled 830, 000 instruc- 
tions. At least several hundred thousand addi- 
tional instructions were developed for other pur- 
poses such as test drivers and specialized 
simulations. Together this represents nearly 
2.5 million instructions written, tested, and 
debugged over the six years of SAFEGUARD 
development, 


The massive amount of radar and digital 
equipment installed at site and at TSCS is visibly 
even more impressive. The radars on the plains 
of North Dakota are monuments to modern 
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Table 4-2 
Size of Major Software Components 


Real-Time Software Instructions 


MDC Application 300, 000 
MDC Exerciser 50, 000 
PAR Application 200, 000 
PAR Exerciser 25, 000 
BMDC Application 60,000 
CLC Operating System 100, 000 


Total 735 , 000 


Support Software Source Statements 


CENTRAN, SNX, XPF, STACS, etc. 210,000 
System Simulation . 50,000 
Exerciser Support 30,000 
Data Reduction 150, 000 


Configuration Management 
Programs 


Fault Logic Simulation 


70, 000 
70,000 
580, 000 


Total 


Installation and Maintenance 
Software Instructions 
MDC Radar Installation tests 
PAR Radar Installation Tests 
Real-Time PAR Radar Tests 
M&D Operating System 
Maintenance & Diagnostic Tests 
ITP, DUX, RTE, NPD, etc. 
Total 


50,000 
110,000 
60, 000 
120,000 
300, 000 
190,000 
830, 000 


technology housing some of the most complex 
electronics in the world.'? Within these buildings 
and at the BMDC site in Colorado and the TSCS 

in New Jersey, hundreds of digital equipment 
racks were assembled to provide the computing 
power needed to control and maintain the de- 
ployed system and its test facility. 


The remainder of this section briefly describes 
the operational aspects of the system. The Com- 
mand and Control Display Subsystem provides 
the facility for monitoring and controlling tactical 
operations and maintenance .27 


Tactical operations are basically concerned 
with integrating the SAFEGUARD weapon system 











into the total national defense structure. If an 
actual threat is detected, the primary tactical 
function is to provide for the timely release of the 
system. Maintenance operations are concerned 
with keeping each element of the SAFEGUARD 
System at the highest availability level possible *-* 
This requires monitoring and coordinating main- 
tenance activities for each subsystem consistent 
with overall tactical demands. Finally, the TSCS 
test facility takes on a new role during the opera- 
tional phase of the system — supporting site 
needs by helping to solve and correct problems 
as they arise.® 


Tactical Command and Control 


The command and control functions in 
SAFEGUARD are divided into maintenance and 
tactical tasks. The maintenance aspects are 
treated separately in the next section. The 
tactical functions are designed to be automatic 
when both feasible and cost effective, with only 
certain key functions assigned to man. These 
manual actions complement the automatic system 
and, except for system release, are not a se- 
quential link in its operation. Hence, man is 
a controller rather than an operator in the 
SAFEGUARD System.?’ 


The Ballistic Missile Defense Center is the 
highest echelon of command and control in the 
SAFEGUARD System. It is collocated with the 
Commander-in-Chief of the Continental Air 
Defense Command (CINCONAD) Combat Opera- 
tions Center (COC) in the Cheyenne Mountain 
Complex at Colorado Springs, Colorado. 
CINCONAD exercises operational command of 
the SAFEGUARD System through the BMDC. 
The BMDC, in turn, controls and directs the 
activities of the Perimeter Acquisition Radar 
and the Missile Direction Center 4°: 


The COC has special nuclear-employment 
authority equipment connected directly to the 
BMDC< In addition, the COC has closed- 
circuit TV monitors on BMDC displays. These 
interfaces provide the BMDC with authorization 
for use of SAFEGUARD nuclear weapons, attack 


warning and other intelligence data generated 
external to SAFEGUARD, alert and readiness 
level coordination with other defense systems, 
coordination with use of offensive forces, and 
requests for special intercepts or satellite ob- 
servations. The BMDC sends SAFEGUARD- 
generated early warning, attack assessment 
data, or results of satellite observations to the 
coc. 


Overall manual command and control functions 
in SAFEGUARD generally relate to implementa- 
tion of actions associated with this COC-BMDC 
interface. All such command and control actions 
at the BMDC, MDC, or PAR require positive 
feedback to man indicating the application soft- 
ware has recognized the manual input. Ifa 
manual action is meaningless or the sequence of 
actions incorrect, the system indicates this to 
man. In addition to validity checks on manual 
inputs, each site performs a validity check on 
any message it receives from other sites. 


A tactical command and control action is 
classified as either a directive or a control ac- 
tion. A directive is manually initiated by higher 
authority and requires a corresponding manual 
action at the PAR or MDC. A controlis manu- 
ally initiated by higher authority and will be auto- 
matically effected at the netted PAR or MDC 
without a local manual action. The Command 
and Control Display Subsystem includes provision 
for display of directives (called forced messages) 
that a tactical officer may implement. The source 
of each directive accompanies the notification. 


System Maintenance 


Maintenance is functionally divided into several 
Maintenance Activity Centers (MACs). The divi- 
sion follows the hardware subsystem division of 
the site; for example, a DPS MAC, Radar MAC, 
Missile MAC, etc. The personnel in each MAC 
are supervised by a Maintenance Director ata 
maintenance console. From this console, he can 
request software-controlled subsystem tests that 
provide current status and fault information. 

The console also allows him to report his status 


to the System Maintenance Director. The System 
Maintenance Director, together with the Equip- 
ment Readiness Officer, man a system monitor 
console in the Equipment Readiness Center. '.6 
In this way, information on all equipment prob- 
lems is conveyed to the tactical command, with 
corrective maintenance controlled and scheduled 
consistent with the tattical needs of the site. 


A number of on-line procedures are available 
to maintenance personnel, The most useful and 
general method is to conduct System Readiness 
Verification (SRV) exercises. The SRV uses the 
system exerciser discussed previously. Sce- 
narios are available to verify specific functional 
and hardware aspects of the system. The SRV 
provides a local or netted system test which 
stresses not only the CLC hardware and its inter- 
faces but also exercises the application software 
under simulated inputs representative of the de- 
sign threat. Other on-line tests periodically 
used for maintenance are the radar Class A and 
B tests, the missile subsystem Class B tests, 
Normal Path Diagnostics (NPDs), and Real-Time 
Exercisers (RTEs). These tools are part of the 
application software and are used during normal 
tactical operation. 


The Class A tests are cycled automatically by 
the application software and measure overall per- 
formance to ensure that the system is meeting 
acceptable operating standards. The Class B 
tests are run on request and are designed for de- 
tailed alignment and performance investigations. 
Whenever the CLC undergoes a reload operation, 
the NPDs are run to test all processor units, 
program stores, and variable stores in the green 
partition, as well as their interfaces, including 
those to the input/output controllers. Once the 
application program is cycling, the Data Proces- 
sing Officer can request the RTEs be run auto- 
matically to test each program and variable store 
every 5 minutes.*! 


A number of off-line maintenance tests also 
are used, Generally, these tests are designed to 
check equipment off-line in the amber partition, 
although a few tests require the full system 


configuration. The M&D Subsystem provides a 
fast procedure to isolate hard faults to a chassis 
or printed circuit board that can be immediately 
replaced. These tests usually employ fault- 
location dictionaries that pinpoint the trouble 
down to a replaceable level.??-* 


Digital Unit Exercisers (DUXs) also are used 
to check individual racks.” These are special- 
purpose equipment exercise and checkout pro- 
grams designed for each unique type of DPS rack, 
Each DUX program provides the capability to con- 
trol the functional operation of a rackon a macro- 
scopic level and to dump the contents of individual 
registers or groups of related registers within 
the rack. Strictly speaking, these exercises are 
not tests but have proved valuable in isolating and 
solving maintenance problems. Some Installa- 
tion Test Programs (ITPs) developed for site 
integration have also proved useful in resolving 
intermittent timing problems and other non-hard 
faults.” The ITPs are being retained at site. 


All of these tests are used for periodic Preven- 
tive Maintenance (PM) procedures. Scheduled 
PM activities are carried out according to pro- 
cedures contained in the Contractor Maintenance 
Data System (CMDS). As PM checks become 
due, maintenance personne] follow the steps listed 
in the CMDS, reporting any faults that occur to a 
maintenance director, Corrective repair activity 
is coordinated with the Equipment Readiness 
Officer to return the system to a fault-free state. 
At less frequent intervals, periodic validation of 
system maintenance is performed using closed- 
loop tracks taken on test objects, such as satel- 
lite and calibration spheres external to the 
system. These techniques help to achieve a cost- 
effective level of maintenance and provide assur- 
ance that the system is properly calibrated and 
aligned. 

All repair operations are conducted off-line. 
When a faulty unit is identified, it is removed 
from the system and replaced with a working 
spare. The faulty unit is repaired in the Tech- 
nical Maintenance Repair Center (TMRC). 
Trained technicians at the TMRC use special test 
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sets and documentation to repair the unit and 
return it to a usable spare stock. 


TSCS Operational Support 


During the operational phase of SAFEGUARD, 
the primary role of the TSCS is to assist the sites 
in resolving any problems that arise. The Con- 
figuration Management procedures used during 
the development phase have been expanded to 
ensure that any changes in the operational weapon 
system are handled in an orderly and methodical 
manner {6.47 


Configuration Management starts with identi- 
fication of a baselined product. The baseline 
consists of the software and its high-level re- 
quirements as used at site. These software 
products include the application software and 
those software tools needed to control, install, 
test, and validate the application software at 
site. The documentation includes Performance 
Design Specifications (PDSs), Data Processing 
System Performance Requirements (DPSPRs),°3"" 
User-Oriented Requirements (UORs), and System 
Design Requirements for Displays and Controls 
(SDRDC).” This baseline was placed under 
Configuration Management control and was the 
version used in final testing. 


Changes to this software baseline and 
SAFEGUARD hardware are rigorously controlled 
by a series of Contractor/Army Review Boards. 
Any problem or proposed improvement, either 
hardware or software, is first documented by a 
Master Problem Report (MPR), which is an out- 
growth of the TR/CR forms used during develop- 
ment. These MPRs are referred to the local 
design organization at the TSCS. Proposed 
solutions are reviewed by a Change Review 
Board for technical accuracy and completeness. 
Technical approval for change is obtained from 
a Direction Committee comprised of Contractor 
and Army management. Approved technical 
changes that affect the baseline are submitted 
as Engineering Change Proposals (ECPs) toa 
local Configuration Control Board. If require- 
ments are involved, the ECP also is sent to a 


System Board for dollar and’ resource approval. 
No changes are permitted at site without the 
necessary approvals. 


Before an approved software change can be 
shipped to site, it must be tested and verified 
at the TSCS. This testing, called Technical 
Verification, consists of a selected set of 
system-level tests. Once the contractor has 
demonstrated these same tests at site, the Army 
conducts User Operational Verification tests 
using tactical procedures and operators. At this 
point, the old software baseline is replaced for 
operational use by the modified product. 


The status of all changes to the baseline is 
tracked from inception of the MPR to final incor- 
poration of the ECP in the baseline. Hardware 
changes are tracked by the On-Site Configuration 
Activity Reporting System which ensures that the 
current site configuration is always available. 
Similarly, software status and various reports 
are generated by the Status Accounting System. 


LESSONS LEARNED 
General 


It is impossible to document all of the lessons 
learned on a project the magnitude of SAFEGUARD. 
Each participant will take with him a wealth of 
experience gained from years of hard, dedicated 
work. And each will have his own view as to 
what is most important. Part II of this report, 
Management and Overall Approach, deals with a 
number of fundamental issues, often involving 
management decision, that relate directly to the 
material covered in this chapter. In the remain- 
ing paragraphs, focus is placed on some of the 
more technical issues encountered, some of which 
may seem obvious but can easily be overlooked in 
the rush to see a large job completed. 


Support Computers 


Early in SAFEGUARD an effort was initiated 
to build a Prototype Development Facility (PDF) 
that would allow program development in a 


time-shared environment on the CLC itself, the 
SAFEGUARD computer. Such an effort seemed 
admirable since it would have avoided the cost 

of providing additional computing hardware for 
unit and element testing. However, it was a 
mistake. This elegant time-sharing tool com- 
peted with demands for CLC time needed to debug 
the machine itself, fo test the SAFEGUARD oper- 
ating system, and to support early application de~ 
velopment, such as installation software. The 
CLC was being used for testing generic programs 
and it could not be tied up developing software 
tools. PDF was abandoned, and very quickly all 
development tools were concentrated on commer- 
cial machines, 


Support Software 


PDF also erred in trying to be too ambitious. 
Other efforts followed this same path. A time- 
sharing system was developed for the GE 635, 
one of the general-purpose computers available 
at Bell Laboratories. This system, the GETSS, 
became operational and supported 20 to 25 users, 
and in many respects was ahead of its time in 
providing editing and execution facilities. But it 
too was misguided. GETSS could not possibly 
support the hundreds of programmers eventually 
required, and more importantly, it was devel- 
oped for the wrong support computer. The pro- 
ject originally was supported by an assembler on 
the IBM 7094. By decision outside the project, 
the 7094 was scheduled to be replaced by a 
GE 635. This led to choosing the GE 635 machine 
to support the time-sharing development. How- 
ever, ultimately, SAFEGUARD management 
adopted the IBM System 370 for project support, 
leaving GETSS out of the mainstream. 


NICOL, the NIKE-X Compiler Language, was 
an attempt to produce a high-level language com- 
piler, similar toPL/1, for the CLC. It was a very 
complicated system and went through a number of 
versions, including one that was to operate on the 
CLC. The evolution of the project and changing 
requirements made it a much too complex 
endeavor. It, like PDF, was abandoned. 
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There is a message in this experience. Sup- 
port software goals must be realistic, particu- 
larly in the sense that they be attainable at the 
time they are required. The purpose of support 
software is, after all, to support the objective 
of building systems. Building support software 
using state-of-the-art techniques is laudable, but 
only if it contributes to the main objective. 


Out of these early attempts evolved a system 
of viable support software for the project. These 
products were available when needed, flexible 
enough to react as requirements changed, and 
reliable. Various methods were used to achieve 
these objectives. High-level languages were 
built on a macro assembler to retain flexibility. 
In fact, flexibility was considered so important 
that efficiency was sacrificed. Software was 
borrowed shamelessly and adapted, but with the 
lnowledge that it would have to be maintained. 
High-risk, state-of-the-art approaches were 
avoided. Incremental implementations were 
planned so that programs could be used as quickly 
as possible. Strict testing and release proce- 
dures were adopted to ensure quality. Programs 
were "frozen" after release and became subject 
to change-control procedures. Stringent control 
was placed over the interfaces among the facilities 
to ensure integrity. All of these techniques 
helped to build a successful support software 
system. 


System Exerciser 


The system exerciser developed for 
SAFEGUARD was a major innovation 383 This 
concept can be widely seen in current develop- 
ment on large software systems. The need to 
provide test signals and data to "drive" any sys- 
tem is clear. As the complexity of the system 
and its operating environment increases, so 
does the complexity of the driver. Therefore, 
it was judged vital to devote considerable re- 
sources to the development of a driver on 
SAFEGUARD, and the effort was started early. 


The costs may seem large at the outset of 
such a development but in the long run they really 
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are not. They more than repay the effort spent. 
As much of the hardware should be incorporated 
in the exercise configuration as is cost effective. 
The impact of the exerciser on the application 
system should be kept to a minimum. And then, 
the exerciser should be tested to create a stable 
base for system testing. 


Patching, Debugging Tools, and Testing 


The ability to patch programs in a controlled 
manner was a major contribution to the 
SAFEGUARD success, A patch to fix a problem 
could be delivered within days to the integration 
team. It eliminated the need for time-consuming 
source code redeliveries and system reverifica- 
tion except at widely spaced intervals. In addi- 
tion, patching provided a flexible, easy-to-use 
tool through which new debugging aids and test 
tools could be created and readily added to the 
test configuration.? 


The importance of unit and module testing can- 
not be overemphasized. A high percentage of 
the bugs found in process and functional integra- 
tion could have been eliminated in the unit testing 
phase. Therefore, it is highly cost effective to 
provide extensive unit and module test facilities. 


Modularity, Redundancy, and Multiprocessing 


In the CLC, the use of well-defined interfaces 
and modular hardware-building-blocks capable of 
communicating within the framework of a dis- 
tributed switching system provide the basis for 
a dynamic computing complex. This structure 
incorporating multiprocessing is capable of 
adding new functional units which offer unique 
economic or performance advantages. The CLC 
can be configured in a wide range, from a single- 
processor to a ten-processor system, and into 
separate computing facilities to provide an in- 
dependent exerciser. 


This architecture can provide high system 
availability without the need for costly and com- 
plete duplication. An additional computing ele- 
ment (processor, store, IOC, etc.) can be added 
as a single replacement in the event of failure in 
that type element. This 'n+1"' approach has 


4-21 


reduced the amount of equipment needed for re- 
dundancy and for system exercise to a fraction of 
that required for a complete standby system. 


Multiprocessing did not present the expected 
conflicts and lock-out problems anticipated. 
Very few such problems were encountered, pos- 
sibly because of the single-application nature of 
SAFEGUARD, as opposed to commercCial appli- 
cations involving an unknown job-mix. But 
probably more important, care was taken to 
address process design. The decision to use the 
task structure, in which each task is a small unit 
of work, was a good one. These tasks were 
scheduled by a table-driven operating system 
rather than being dynamically scheduled. Avoid- 
ing the use of interrupts for switching between 
tasks was very deliberate and was the key to 
maintaining sanity in a large application with 
many tasks competing for resources. 


It was good design practice to use short-running, 
low-priority, asynchronous tasks wherever pos- 
sible. This helped alleviate schedule conflicts 
that would arise if there were a large number of 
high-priority synchronous tasks. It guaranteed 
that high-frequency, high-priority tasks would 
execute as desired, and aided in distributing the 
workload over a longer time-frame. 


Error Control 


The following items are a few key points and 
recommendations based on the SAFEGUARD ex- 
perience with error control. The recommenda- 
tions are generally applicable to any large-scale, 
real-time control system. 


Component redundancy and multiprocessor 
design are inherently fault-tolerant. Similarly, 
software architecture is fault-tolerant if it has 
multiple instances of tasks to do specific functions 
(e.g., n track functions to update data on any of 
n objects), if the processing work is divided into 
many small independent tasks, if the software 
control is decentralized, if there is emphasis to 
confine errors locally, and if there are system 
error responses to reinitialize the system to 
replace faulty hardware components. 


System error control guidelines and structure 
should be defined early? They are required if 
the total system is to have a consistent approach 
to error control. Error logging throughout the 
system should be the first guideline. The next 
is to design a structure so that error responses 
can be easily modified. The logging is an in- 
valuable debugging todl. And as operational ex- 
perience on error occurrence rate is gained, the 
response can be appropriately modified. 


Finally, manual error control or manual 
override should be provided even for automatic 
and self-repairing systems. It is invaluable in 
“bringing up" a faulty system to isolate a com- 
plex problem when the automatic software fea- 
tures have failed to circumvent the trouble. 


Maintenance Approach 


Experience to date has demonstrated the fund- 
amental power and flexibility inherent in the two 
primary Maintenance and Diagnostic Subsystem 
(M&DSS) features. These are the extensive data 
bus interface with the entire DPS and the general- 
purpose computing capability of the Maintenance 
Data Processor ,32-35 


In retrospect, the total range of M&DSS capa- 
bilities has yet to be explored fully. For example, 
because of project schedule constraints, the 
logic-block partitions originally defined have not 
been changed. But different partitions, chosen 
with timing faults in mind, might allow these 
faults to be handled via the fault dictionary 
method. (In this case, it also would be necessary 
to increase the speed of the entire M&DSS which 
now runs two orders of magnitude slower than 
many of the internal logic events in the DPS.) 

' Other diagnostic tools, such as the Installation 
Test Programs, could be restructured with fault 
isolation more in mind, thus yielding isolation to 
the chassis level.” 


Development of Computer Languages 


CENTRAN was developed to produce code for 
the CLC. It is an extensible language whose ex- 
tensions approximate PL/1 in control structure 
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and. FORTRAN in data structure.“ A number of 
lessons were learned during its development and 
use, 


The designers, implementers, educators, and 
users should not be disjcinted groups. The de- 
signer should be involved as an implementer 
to keep in touch with reality. He should also 
be involved as an educator (if a feature is diffi- 
cult to explain, maybe there is something wrong 
with it) and as a user (uniformity in extension is 
best achieved by knowing how the language is 
being used.) The implementer should act as both 
educator and program counselor to get feedback 
on bugs being "programmed around" and to estab- 
lish priorities for fixing them. 


Several things about the implementer-user 
relationship should have been learned earlier in 
CENTRAN development. First, the release cycle 
should be rigidly controlled as soon as possible, 
no matter how short the cycle. It does not pay 
to be a "nice guy" and give "fixes" to bugs inform- 
ally. Next, old versions of the compiler should 
not be kept around and certainly not maintained. 
The maintainers are blamed for bugs that no 
longer exist, and much time is spent rediscover- 
ing causes for problems long since solved. 


Notices of new releases must go to everyone, 
not just supervision. Users often underestimate 
the impact on schedules of changes due to im- 
provements to the compiler, even though the 
improvements were requested. 


Insofar as the designer-educator-user relation - 
ship is concerned, the designers should have been 
more involved in determining the structure and 
content of the CENTRAN courses. Frequent 
symposia (e.g., Advanced Topics in CENTRAN 
Programming) should have been held, with com- 
pulsory attendance. 

CENTRAN should have been an expression 
language. This not only would have aided the 
production of more efficient, clearer, and more 
concise code, but would have provided a greater 


degree of uniformity to the language. 


More thought should have been given to data 
types required for data reduction. Maintenance 








of CENTRAN programs (especially patching) 
should have been given greater priority in the 
design of CENTRAN. 


Several of the CENTRAN design approaches 
were advantageous. CENTRAN was implemented 
by a small group of programmers. This ap- 
proach avoided communication and other prob- 
lems typically encountered with a large group of 
programmers, 


The register allocation mechanism, subrou- 
tine interface primitives, and extensibility 
mechanism designs worked well, as exhibited by 
CENTRAN's short development time. The ability 
to have partial word variables has been found 
useful. The ability to program at several levels 
in one language made the language suitable for 
systems and applications programming. Finally, 
and most important, the design of the extended 
language was sufficient for the implementation 
of SAFEGUARD software, and SAFEGUARD pro- 
grams have been successfully implemented in 
CENTRAN. Several studies of the suitability of 
CENTRAN for SAFEGUARD have been made out- 
side of Bell Laboratories, and all have concluded 
affirmatively. 


System Programming in PL/1 


The Execution Preparation Facility (KPF) 
performs the linkage editor function on the IBM 
370 for CLC software.” It was decided to de- 
velop XPF in PL/1. Throughout the development, 
many design and implementation decisions con- 
cerning the use of PL/1 were made. Some of 
these proved to be sound and others had unfor- 
tunate results. 


The extensive use of the PL/1 preprocessor 
proved to be an excellent control mechanism. 
The inclusion of macros, entry point declara- 
tions, and global variable declarations via pre- 
processor procedures greatly facilitated inter- 
module communication. This standardization 
guaranteed the integrity of interface. 


As originally expected, the liberal use of PL/1 
debugging aids was an invaluable development 
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tool. The large number of logic errors detected 
through on-conditions such as SUBSCRIPTRANGE 
and STRINGRANGE underlines the value of their 
use. 


The use of assembly language subroutines, 
although dictated by efficiency and necessity, 
presents some disadvantages, Since parameter 
definition is compiler-dependent, assembly lan- 
guage subroutines must be coded to meet the 
parameter-passing standards and conventions of 
a specific compiler. In PL/1, these proved even 
more limiting since assembly language subrou- 
tines must be coded for a specific version of the 
compiler. When such subroutines are utilized, 
this dependency on a particular version of a com- 
piler should be explicitly documented. 


One benefit of using PL/1 not considered in 
the original decision was the ease with which 
transfer of responsibility was accomplished. 
Partial turnover of personnel occurred throughout 
the project. Transfer of code responsibility to. 
new personnel was accomplished very smoothly 
with no apparent decrease in productivity. Since 
PL/1 can be largely self-documenting through the 
use of meaningful variable names and standard 
operation symbols, it is easy to read and under- 
stand. This ease of understanding was the pri- 
mary reason for the smooth personnel transitions. 


Professional Design Review . 


For part of the application program develop- 
ment, a technique known as "flowchart review" 
was undertaken. As soon as the flowchart and 
data set layouts for an area of the program were 
completed — and before coding began — a review 
meeting was held. The programmer was re- . 
quired to give a box-by-box explanation of a 
detailed flowchart for his program to a small 
group of his colleagues. In as friendly a manner 
as possible, this review committee was expected 
to be critical and to question aggressively every 
assumption that the programmer made. 


After such a review, the programmer coded 
his unit, tested it, and released it to process 


integration. Any minor changes due to bugs 
found during integration had to undergo a second 
type of review. Each programmer submitting a 
minor change was required to select a referee 
from among the senior members of the group. 
The programmer would discuss with the referee 
both his proposed change and the procedure to be 
used in testing the chahge. The change could not 
be released until the referee was satisfied with 
the testing as well as with the code itself. After 
the referee system was introduced, the problem 
of bugs in minor changes came to an end. 


One lesson learned from these experiments is 
the extent of the increase in quality and produc- 
tivity that can be obtained from a disciplined use 
of professional review. The use of flowchart 
review: 


Improved and simplified software design. 


e Helped detect all major software design 
errors before code was written. 


@ Reduced software development time by at 
least 25 percent. 


e Improved quality of delivered software. 
The referee procedure brought an end to 
the errors in minor changes turned over 
to the system integration team. Other 
forms of professional review have led to 
similar results. 

A second significant lesson can be learned by 
comparing professional review with some of the 
other techniques that also have led to improve-~- 
ments in program quality and programmer pro- 
ductivity; e.g., programming teams, modular and 
top-down design, and structured programming. 
There is a common denominator to these tech- 
niques — the increased structure and discipline 
that is placed on the process of writing software. 
Although much remains to be learned about 
writing software, it is clear that designing and 
writing software needs to be a much more struc- 
tured process than it generally is today. 


Software Change Control 


Two aspects of software change control that 
were successful in SAFEGUARD were a project- 
wide library maintenance system to control 
source and object code and a standard trouble 
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report form. These were not developed over a 
long period of time, but appeared very early in 
the project. Because of this stability, software 
developers grew accustomed to using them. The 
library maintenance system was available during 
the first phase (no change control), and the trou- 
ble report form was available at the beginning of 
informal change control. It was recognized that 
early introduction and acceptance would be bene- 
ficial because transition to the later phases would 
be simplified. Two additional features of the 
system, change control procedures and software 
status accounting, proved to be more trouble- 
some to define and implement. Early in the 
period of informal change control, each process 
area independently developed its own procedures; 
thus a certain amount of reexamination and re- 
definition were required during the transition to 
formal change control. 


Any software change controlsystem is destined 
to meet with some resistance. Programmers as 
a rule have very definite ideas about what should 
be done to their software. This factor, combined 
with the dynamic nature of software, makes change 
control a difficult problem, not so much in estab- 
lishing the mechanisms and procedures, as in 
dealing with human factors andensuring adherence 
to procedures. The first step is to recognize 
that change control is a necessity that should be 
addressed early on any large project and, in fact, 
will be addressed, either early in a systematic 
manner or later in a less organized but more 
costly manner. Only the recognition of this need 
and conscientious addressing of acceptable pro- 
cedures will guarantee successful change control. 
These human factor aspects are the more impor- 
tant considerations in successful software change 
control. : 


System Constants 


The SAFEGUARD application software contains 
thousands of numerical values or constants to 
specify site parameters (e.g., radar location), 
hardware characteristics (e.g., transmitted 
power), physical modeling (e.g., air density 








sal 


profiles), etc. Accurate constants were needed 
by designers in many different areas of each 
application process, Early in process integra- 
tion, a group was assigned the task to identify, 
validate, and control the values of all such sys- 
tem constants, Once this was done, no signifi- 
cant problems caused by improper numerical 
values occurred during the final integration and 
testing of the SAFEGUARD software. 


While this effort was successful, it is clear 
that the specification and control of constants 
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should have been considered during the initial 
design of the software processes. Had it been 
addressed earlier, undoubtedly it would have 
resulted in some special design features. These 
thousands of constants could have been controlled 
in a less burdensome manner either at process 
construction time, during process initialization, 
or during execution, by using special constant _ 
data sets. The special features could also en- 
compass easier procedures for verifying and 
changing values. 
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System evaluation attempts to estimate total 
system performance in order to provide confi- 
dence that the overall system objectives will be 
achieved. Executing this task in the SAFEGUARD 
program involved two major phases of activity. 


The first phase focused attention on the per- 
formance and functional requirements specified 
by the tactical system designers and documented 
in the performance specification for the hardware 
and in the Data Processing System Performance 
Requirements (DPSPRs) !” for the software. The 
goal of this phase was to verify the viability of the 
overall system design and to discover and correct 
any inadequacies in system operation as early as 
possible. Another objective was to identify crit- 
ical aspects of system performance to assure that 


appropriate emphasis was reflected in system re~ _ 


quirements and that appropriate test programs 
and associated test requirements were identified 
and planned. 


The second phase broadened the scope of the 
evaluation effort to ensure that the design imple- 
mentation satisfied the design requirements. 
During this period, system and subsystem models 
were modified and validated using data collected 
from field and laboratory tests. Corresponding 
adjustments were made to estimates of system 
capability. 


Chapter 5. 


SAFEGUARD SYSTEM EVALUATION 
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Obviously, the SAFEGUARD System evaluation 
was an evolutionary activity, proceeding from 
system requirements to system implementation. 
The objective was to obtain adequate data to per- 
mit a confident assessment of system capability 
in the most cost-effective way. This was accom- 
plished by identifying the appropriate function of 
each of the available sources of data and estab- 
lishing how the various simulations, subsystem 
tests, and system tests would supplement-each 
other. 


APPROACH TO SYSTEM EVALUATION 


SAFEGUARD System capability was evaluated 
primarily through simulation, with test data 
serving to validate the simulation modeling and 
add confidence to the evaluation results. The 
hierarchy of simulation tools developed ranged 
from a total system simulation capable of indi- 
cating the response of all system elements during 
a typical attack to much more detailed simula- 
tions of critical system functions such as battle 
planning, data gathering (target track), and inter- 
cept (guidance and missile performance). 


Figure 5-1 diagrams the primary interfaces 
among the design, evaluation, and test activities. 
Evaluation, primarily an analytic activity, relied 
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heavily on simulation because of the complex na- was particularly valuable with respect to the ia 
ture of the SAFEGUARD System. Hence, in Fig- SAFEGUARD target-track and intercept functions i 
ure 5-1, evaluation is represented by the major and to performance of the Missile Site Radar S23 
simulations developed. Three sources of test (MSR) and the SPRINT and SPARTAN missiles. 
data were relevant to system evaluation activity This test site, however, could not provide all re- 
and played a major role in simulation validation: quired test data nor a complete test of 


SAFEGUARD System operation for the follow- 
e Tactical Software Control Site (TSCS), Hig reasons: , 


e Meck System Test Program 


Madison, New Jersey e Impracticality of providing threat traffic 


e Tactical Sites — Grand Forks Air Force : commensurate with the design threat — 
Base, North Dakota, and Colorado Springs, many aspects of system performance ais 
Colorado. could not be stressed at low traffic levels. 2 
For tests at Meck Island, Kwajalein Atoll, . teeing “oe cee. Na aedieiea oe : = 
live" ICBM and SLBM targets were available and minimize the effects of self-blackout. : 
were tailored to the program requirements and poe eee NE ce es 
engaged by defensive missiles. Meck data a 


coat 


e Lack of critical system elements ~ the 
Meck test facility did not include a Perim- 
eter Acquisition Radar (PAR) and because 
of the lack of nuclear effects and high 
traffic, the data processing software did 
not include battle-planning functions. 


e@ Expense of live testing — the cost associated 
with a single live test limited the number 
and variety of tests that could be conducted. 

The Meck System Test Program is discussed 
more completely later in this chapter. 


Tests conducted at TSCS were a major source 
of data for simulation validation, particularly in 
those areas not covered by the Meck System Test 
Program. By using the System Exerciser (SYSEX) 
to provide high traffic and the nuclear environ- 
ment, data was available for evaluating several 
system functions including battle planning and tar- 
get selection. Because TSCS included both the 
PAR and MSR data processing systems, data was 
provided in the netted-system environment not 
available from the Meck System Test Program. 


The Meck test facility did not include a proto- 
type PAR, hence tests conducted at the tactical 
PAR site provided the necessary PAR perform- 
ance data. In addition, system tesis initially 
conducted at TSCS were repeated at the tactical 
sites, supplementing the system performance 
data gathered at TSCS and utilized in simulation 
validation. 


The remainder of this chapter describes the 
major simulation tools developed during the eval- 
uation program, the procedures by which these 
simulations were validated using test data, the 
key analysis and results obtained with the simu- 
lations during the evaluation program, and de- 
tails of plans and results of system testing at 
Meck and at Grand Forks. Also included is a 
description of the system integration and demon- 
stration tests conducted at TSCS and Grand 
Forks for system certification and customer 
acceptance. 


MAJOR SIMULATIONS 


Several simulations were developed to assist 
in evaluating the system. These simulations 
proved to be a valuable tool in the overall evalua- 
tion program. 


System Simulation 


The complexity of the SAFEGUARD System 
and the complex interactions between functions 
made it difficult to predict the overall system re- 
sponse and effectiveness during a typical attack. 
The SAFEGUARD System Simulation (SAFSIM/ 
TACSAF), which uses the HIS 635 computer, was 
developed to evaluate system response and to de- 
termine system effectiveness over the spectrum 
of threat conditions. Two versions of the simula- 
tion were developed. The first, SAFSIM, was 
used early in the evaluation program to evaluate 
the DPSPRs. SAFSIM consists of models of each 
of the system functions designed to meet the per- 
formance requirements unconstrained by any 
real-time data processing limitations. A second 
version of the simulation, TACSAF, has models 
representing the ''as implemented" tactical capa- 
bility and incorporates knowledge gained from the 
various test programs, in particular the Meck 
System Test Program. The major elements of 
TACSAF are listed in Table 5-1.? 


The level of detail included in the various 
functional models varies over a wide range. 
For example, the MSR track function is not a 
closed loop as in the MSR Simulation (MSRSIM)‘ 
discussed next, but uses a statistical error 
model to represent pulse-by-pulse variations 
in the track data provided to the track filter. 
The statistical model was developed using re- 
sults from MSRSIM and includes Signal-to- 
Noise Ratio (S/N) effects and the effects of the 
wake and tank-breakup environments. Similarly, 
the SPRINT intercept model is greatly simplified 
because guidance algorithms are not included. 
SPRINT miss distance is estimated as a statis- 
tical combination of target-track and missile- 
track uncertainties amplified by a factor that 
depends on intercept geometry. This simplified 
model was based on extensive simulation of the 
guidance loop using SES/SIS (see SPRINT Engage- 
ment Simulation), which in turn was-validated in 
connection with the Meck System Test Program. 


Conversely, the SPRINT Interceptor Response 
(IR) function essentially duplicates the tactical 
algorithms, as does the Target Selection 


Table 5-1 
Major Elements of the SAFEGUARD System Simulation (TACSAF) 


TRAJECTORY GENERATOR 


e Target Reentry Vehicles (RVs) — Input RV ballistic coefficient history, launch point, impact 
point, reentry angle, launch or impact time , 


e Tank, Junk Dispersion — Input AVs relative to RV velocity 


SURVEILLANCE/DETECTION MODEL 
e Threat Characteristics — Radar Cross-Section (RCS) models; vehicle dynamic motions 
e MSR Search Sectors 


MSR TRACK 


e MSR Weapon Process (MW) Data Gathering Logic — Data rates, track priorities, Automatic 
Gain Control (AGC), waveform switch 


e Target Selection 
e Discrimination 


ENVIRONMENTAL MODELS 
e Nuclear Blackout/Attenuation 
e Wake Effects 
e Tank-Breakup Effects 


RESOURCE ALLOCATION/OVERLOAD RESPONSE 
e Dynamic Accounting of MSR and Missile Site Data Processor (MSDP) Loads 
e@ MW Logic for Radarand Data Processor (DP) Overload Response 


INTERCEPT PLANNING (SPRINT Interceptor Response) 
e Farm Selection Logic 
e Constraint Resolution 
Nuclear Models — Blackout, radiation, shock, dust 
SPRINT Deadzone. 
Wake Avoidance 
e SPRINT Capability (flyout, acceleration) 


INTERCEPT ASSESSMENT 
e Miss Distance Determination (True and Estimated) 
e Interceptor Lethality Contours 


PENETRATOR EFFECTS 
e Facility Damage — Shock, dust 
e Nuclear Blackout 
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Function (TSF). The SPRINT IR and TSF modules 
can both be exercised as part of the total simula- 
tion or can be exercised in a "stand-alone" pack- 
age for separate response analyses. 


To achieve reasonable fidelity, TACSAF is 
necessarily an extremely large and complex sim- 
ulation. Some list-handling. and dynamic-storage 
techniques not commonly found in FORTRAN sim- 
ulations assisted greatly in program organization. 
Also, TACSAF is event-based to minimize com- 
puter resource usage. This means that time is 
not the independent variable, but rather a time- 
ordered list of significant events is processed. 
No computations are performed in between signif- 
icant events and time is merely updated to corre- 
spond to the time of the event under consideration. 
As an aid to analysis, convenient summaries can 
be produced by processing the data recorded on 
magnetic tape during a TACSAF run, A partial 
list of the summaries currently available in 
TACSAF includes: 

e Overview of Significant Events — Object-by- 
Object 
Detection Summary 
MSR Target Selection Function 
MSR Discrimination 
Clutter Effects Summary 
SPRINT IR Planning Summary 
SPRINT Engagement Summary 


Resource Allocation Summary - Radar and 
DP Loads versus Time. 


In addition to tabulations of the summary data, 
plot routines are available for several of the 
summaries, 


TACSAF was used for a wide range of system 
evaluation activities, including the system traffic- 
handling capability and overload response and a 


detailed evaluation of the battle-planning functions. 


TACSAF also provided an extensive data base of 
expected results for the set of System Integration 
and Demonstration tests conducted at both the 
TSCS and tactical site. The performance criteria 
and bounds for those tests were developed from 
the data base. 


MSR Simulation 


The primary objective of the SAFEGUARD Sys- 
tem was to detect, identify, and intercept threat- 
ening reentry vehicles. Data from the target- 
track function, ‘of sufficient quality to support 
target selection and intercept, was critical to 
attaining the primary objective. The MSR Simula- 
tion (MSRSIM), which runs on the HIS 635 com- 
puter, was developed to permit a comprehensive 
evaluation of the SAFEGUARD target-track func- 
tional capability; 


The main features of the simulation are de- 
tailed models of target characteristics and models 
of the radar hardware and data processor soft- 
ware, which are included in the tracking loop. 
MSRSIM consists of two modules of simulation 
programs, the BED programs that model the 
radar hardware and threat environment and the 
LOGIC programs that model the data gathering 
software. 


Features of the threat environment modeled in 
the BED module are: 


RV radar cross section and sheathing effects 
RV dynamics (trajectory and tumbling) 

Wake parameter histories 

Ballistic coefficient histories 

Tank fragmentation. 


The BED hardware models include: 


Main lobe antenna pattern 

Sum-channel video with correlated noise 
Range mark generator 

Monopulse phase detector 

Digital encoder granularities 

T1 and T3 compressed waveforms 
Dispersed pulse measurement. 


Modeled features of the data processor algo- 
rithms in the LOGIC module are: 


Acquisition and track initiation 
Kalman track filter 

Crossing target logic i 
AGC and track-mode selection logic 


Range gate ‘setting and antenna beam 
pointing 
Tracking status assessment. 


Detailed mathematical models of the radar sig- 
nal processor and high-fidelity signal synthesizers 
are the heart of MSRSIM. For the MSR, the mod- 
els digitally synthesize compressed-pulse video 
and monopulse-angle processor signals and 
dispersed-pulse integrator signals, including the 
effects of bandwidth-limited noise. Backscattered 
signals from waking and/or fragmenting objects, 
which may be off-axis in the phased-array main 
beam, are appropriately superimposed to create 
realistic radar responses. The model accurately 
represents the interference backscatter from 
multiple targets by considering their relative 
ranges from the radar and their off-beam posi- 
tions. Gain states of the radar, waveforms trans- 
mitted, and other factors influencing the phase and 
amplitude of the interfering returns from targets 
are also represented. 


The time-based simulation is stepped ahead to 
the time that the next radar pulse is transmitted 
to the next object in track, After all objects are 
flown prior to the time of the next radar pulse, 
their radar cross sections are computed. The 
objects include reentry vehicles, tanks, and tank 
fragments, all of which may wake during reentry. 
Next, the sum-channel video signal is generated 
and range and amplitude measurements are taken, 
Simultaneously (to represent the monopulse-angle 
measurements), sin @ and sin 8 difference- 
channel signals are generated and combined with 
predicted sum-channel signals to generate noisy, 
off-axis sin @ and sin 8 measurements. The 
range, amplitude, and sin a and sin 8 measure- 
ments are digitally encoded and passed to the data 
processor software. If the amplitude S/N is above 
a threshold, the measurements are inserted into 
the Kalman tracking filter to update the estimated 
target-state vector and to estimate target position 
and velocity at the time of the next pulse trans- 
mission, Estimated position information is fed 
to the hardware model to point the antenna beam 
and set the range tracking gate for the next pulse 
transmission. Simultaneously, the estimated 
variances and peak amplitude S/N are sent to the 
track-logic software to determine the RF gain 
setting and the track mode, 
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Different versions of the simulation are avail- 
able. All use the same BED module, but different 
LOGIC modules. One version of the simulation, 
using a LOGIC package consistent with the Meck 
data processing, was used extensively in defining 
Meck test requirements, providing premission 
simulations, and evaluating mission results to 
validate the simulation. A second LOGIC package 
was used in developing the tactical tracking algo- 
rithms. This version of the simulation was 
labeled TACMSRSIM. 


PAR/SPARTAN SAFSIM 


_A decision was made in 1972 to develop a sep~ 
arate version of SAFSIM to model the PAR/ 
SPARTAN system response. The development of 
separate PAR/SPARTAN and MSR/SPRINT ver- 
sions of SAFSIM was desirable, since the amount 
of computer storage required by a single simula- 
tion would have necessitated sophisticated and ex- 
pensive disc-to-core program swapping techniques 
to fit the simulation into the available core storage 
on the HIS 635 or IBM 370 computers. No anal- 
ysis capability was lost through this simpler and 
cheaper approach of developing two separate ver- 
sions of SAFSIM. Also, a low degree of inter- 
action existed between the PAR/SPARTAN and 
MSR/SPRINT roles in SAFEGUARD. PAR/ 
SPARTAN SAFSIM (P/Z SAFSIM) was developed 
on the IBM 370, because the execution speed and 
core storage advantages were needed for simu- 
lating the large number of objects visible to the 
PAR during a battle. For example, simulation of 
one of the full system integration test scenarios 
on P/Z SAFSIM requires 1200 kilobytes of stor- 
age and 1- to 1.5-hours execution time on the 
IBM 370/165. 


The attack environment portion of P/Z SAFSIM 
consists of models of the key attributes of each 
threat complex type (e.g., RV/tank separation 
velocities, RCS profiles), trajectory targeting 
programs, and exoatmospheric nuclear environ- 
ment models. The satellite environment was not 
simulated since it was found to have an insignifi- 
cant effect on system response during an attack. 








The PAR surveillance function is approximated 
in P/Z SAFSIM. Rather than implement a de- 
tailed search-raster model, the time for the first 
surveillance-pulse hit on an object is determined 
by a random draw from a uniform distribution, 
with later attempts scheduled deterministically 
using the scan time of the subsector. The effects 
of radar resource availability on scan times and 
of nuclear burst attenuation on detection capabil- 
ity are modeled, The scan-while-track and 
search~in-range detection mechanisms used by 


the PAR Weapons Process (PW) are also modeled. 


PW rules for the traffic-level-dependent switch 
on maximum search listening range are 
implemented, 

Te 


In the tracking area, accurate models are in- 
corporated for track initiation and group clus- 
tering, automatic gain control, pulse scheduling, 
polynomial/Kalman filtering, known object recog- 
nition, and lowS/Nsample pulsing response. Due 
to excessive execution time and storage require- 
ments, a signal processor model was not included 
in P/Z SAFSIM, Thus, in unresolved target- 
track situations, the SAFSIM tracking perform- 
ance was not an accurate reflection of PAR track- 
ing, and it was necessary to use the detailed 
radar evaluation simulation (PAR Testbed) in 
conjunction with P/Z SAFSIM. 


The four key subfunctions of PW target selec- 
tion are modeled in P/Z SAFSIM: determining 
value structure attacked, determining launch 
complex type, ranking objects according to esti- 
mated probability of being an RV (Pry), and re- 
scaling Ppy to support the SPARTAN Interceptor 
Response (ZIR) missile allocation function. 


For battle planning, portions of the simulated 
models were implemented for defense-mode- 
dependent SPARTAN allocation, battlespace de- 
termination, Minuteman-flyout-corridor avoid- 
ance, manual SPARTAN controls (SPARTAN 
Hold and Hold Fire), and intercept-point selec- 
tion. Particular attention was given to intercept- 
point selection due to the complexity and impor- 
tance of the problem of resolving nuclear effects 
constraints, such as fratricide and blackout 
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The ZIR models 
were also configured to runin a stand-alone mode 
outside the body of P/Z SAFSIM. This facili- 
tated detailed high-fidelity analysis using PW 
inputs from the PAR Testbed Simulation or TSCS. 


among multiple intercept points. 


Finally, the SPARTAN intercept effectiveness 
model simulated both controlled and free- 
intercept guidance modes, using forced or un- 
forced jethead ignition, as appropriate. The 
primary error sources modeled were atmospheric 
exit velocity errors, missile state estimation 


" errors at third-stage ignition, third-stage veloc- 


ity errors, and third-stage spin-stabilization 
errors. 


PAR Testbed 


PAR Testbed is a high-fidelity simulation of 
the threat environment, PW software, and PAR 
hardware. The threat environment models offer 
the same capabilities as those described for 
PAR/SPARTAN SAFSIM. In addition, the Test- 
bed can be driven directly by SAFEGUARD 
Threat Action Generator (STAG) tapes (see Sys- 
tem Integration Testing) for precise simulation 
of the threat environment encountered in TSCS 
tests. The satellite and meteor environment is 
also simulated. 


The PW software portion of Testbed includes 
detailed models of the raster-scan search and 
verification processing. In the track area, 
models are provided for track initiation, includ- 
ing range rate histograms, correlation proces- 
sing, and Known Object Recognition (KOR) checks; 
Continental United States (CONUS) impact and 
meteor tests; pulse scheduling rules, including 
scan-while-track, search-in-range, drop track, 
sample pulsing, and lost track algorithms; KOR 
checking throughout track processing; clustering 
and reclustering logic; and finally, Kalman and 
polynomial filtering for both null and off-axis 
tracks. In the target-selection area, models are 
provided for each of the subfunctions that lead up 
to determining value structure attacked and 
launch complex type, ranking objects according 
to estimated probability of being an RV (Pry), 


and rescaling Ppy to support the SPARTAN Inter- 
ceptor Response missile allocation function. Fi- 
nally, the traffic sensitive switch of search lis- 


tening range and pulse allocation rules is modeled. 


The PAR hardware models include interfering 
multiple-target effects in range and angle, and 
correlated noise effects in range. Range marks 
are generated from simulated noisy range video. 
Angle measurements are modeled by forming a 
sum~signal vector and two difference-signal vec- 
tors (including noise and jitter effects) and by pre- 
cisely modeling the characteristics of the mono- 
pulse detectors, Simulated signal levels and 
noise levels are impacted by the pulse-by-pulse 
setting of digitally controlled attenuators. Finally, 
the characteristics of the Tl waveform (beam- 
width, sidelobe levels, etc.) have been modeled 
in detail. 


SPRINT Engagement Simulation 


Two detailed simulations were used to evaluate 
SPRINT intercept capability in the SAFEGUARD 
System, The SPRINT Engagement Simulation 
(SES) was developed to evaluate the performance 
requirements applicable to SPRINT capability 
(primarily guidance) and to support the definition 
of requirements for the SPRINT intercept portion 
of the Meck System Test Program. All elements 
of the SAFEGUARD System necessary to the en- 
gagement of a single RV by a single SPRINT mis- 
sile were modeled in SES. A detailed simulation 
of the SPRINT missile was provided, including 
statistical models of all significant performance 
variations such as pitchover errors, motor thrust 
and total impulse, autopilot biases, etc. The 
guidance program implemented in SES contained 
all of the guidance functions specified in the 
DPSPRs for SPRINT guidance, but were non-real 
time in the sense that they were not constrained 
by real-time data processing considerations. 
Both the target-prediction and missile-prediction 
functions provided accuracies not achievable in 
real time to serve as a base for evaluating tac- 
tical implementation. 


Models of missile and target track were devel- 
oped consistent with the MSR performance speci- 
fications and results obtained from MSRSIM. As 
indicated earlier, SES was used initially to iden- 
tify stressing intercept conditions for use in de- 
fining the Meck test requirements. 


As the tactical guidance design for SPRINT 
was developed, the guidance section of SES was 
replaced with tactical algorithms. Using per- 
formance data from the Meck System Test Pro- 
gram, the missile simulator was modified and the 
target-track model was extended to simulate 
target-wake effects and other clutter sources, 
such as tank breakup. 


SES was used extensively throughout the SAFE- 
GUARD evaluation program to thoroughly explore 
SPRINT intercept capability throughout the field 
of fire and to investigate the sensitivity of inter- 
cept capability to guidance design alternatives 
and variations in environment. 


The major studies conducted*" included: 


e Determining the linear region of the 
SPRINT field of fire 


e Determining the effect of wake-induced 
target-track biases on intercept capability 


e Characterizing controlled guidance effec- 
tiveness in limiting intercept-point shift 


e Determining the sensitivity of intercept 
capability to variations in target- and 
missile-track rates and guidance rate 


e Determining sensitivity to variations in 
missile performance, air density, target 
beta histories, and other environment 
factors including blackout-coast intervals 


e Evaluating the tactical algorithm design, 
including missile and target predictors, 
intercept-point bias, and capability bias 


e Developing an approximate intercept capa- 
bility model for use in the system 
simulation. : 

SPRINT Intercept Simulation 


The SPRINT Intercept Simulation (SIS) is a 


, Monte Carlo simulation containing all the ele- 
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ments of the subsystem, with-the exception of 
the target-tracking and -state estimation func~ 
tions. Target-state estimation information is 








Baler 


supplied to SIS via magnetic tape generated by the 
MSR simulation, MSRSIM. The prelaunch guid- 
ance and missile data processing functions con- 
tained in SIS are FORTRAN equivalents of the . 
real-time M-2 software code used for the live 
missions at Meck. The missile simulator and 
MSR missile-track error simulator are FORTRAN 
models of the SPRINT missile and MSR missile 
track hardware, which contain models of all 
error sources that significantly contribute to 
intercept effectiveness. 


The overall approach to intercept subsystem 
evaluation developed during the Meck program 
consisted of three major phases:!! 


e Analysis and simulation 
e Stressing tests 
@ Reconstruction of test results. 


Simulations and analysis techniques were de- 
veloped to verify system and subsystem require~ 
ments, and to characterize system performance 
to hardware, software environment, and threat 
parameters. The parameters that drive system 
performance (e.g., radar noise, unpredictable 
target accelerations, variations in missile per- 
formance) are of a random statistical nature, and 
the properties of the system are highly interactive 
and nonlinear; therefore, it is not generally fea- 
sible to determine intercept effectiveness by 
analytical techniques. Consequently, Monte 
Carlo simulation techniques were required to 
adequately characterize system performance. 


Since the cost of a Monte Carlo live-mission 
approach to validating system performance at 
Meck was obviously prohibitive, the approach 
was to use data gathered from a relatively small 
number of particularly stressing live missions to 
validate Monte Carlo simulations. These tests 
were specifically designed to stress some aspect 
of missile or software performance and to provide 
data to validate simulation models and techniques 
(see SPRINT Performance Characterization). 


The live-mission results were constructed by 
simulation using the data gathered during the live 
mission. If reconstruction was successful, 
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confidence was developed in the validity of the 
simulation and, consequently, in the accuracy of 
the system performance predicted by the simula- 
tion. If reconstruction was unsuccessful, defi- 
ciencies in modeling or simulation techniques 
were exposed and corrected. 


To use simulation results to characterize 
SPRINT intercept subsystem effectiveness with a 
high degree of confidence, the simulation itself 
had to be a valid model of the subsystem. The 
SIS verification analysis used premission Monte 
Carlo simulation, live mission, and post-mission 
Monte Carlo simulation results. Premission 
simulation analysis provided nominal guidance- 
and missile-parameter histories and predicted 
possible mission outcomes. The final post-mis- 
sion simulation analysis consisted of reconstruc- 
ting the flight and matching flight test and simu- 
lation results. 


The premission Monte Carlo simulations with 
SIS used MSRSIM tapes of target-state histories. 
In most cases, the MSRSIM tapes contained 25 


‘Monte Carlo samples of estimated target-state 


histories representing different random target- 
track noise and variations in target ballistic 
coefficient histories. For the premission simu- 
lations, all other random system errors that 
influence intercept effectiveness (missile-track 
noise, missile performance variations, and 
atmospheric density) were fully simulated. 


During the post-mission analysis, data gathered 
during the live mission were used to particularize 
the conditions actually present during the mission 
and to "'tune''the simulation models and conse- 
quently reconstruct the flight. Three major 
classes of data were gathered during each flight: 
Recorded software parameter histories 
(E-Tape) 

Missile telemetry data 


Optical track data - Recording Automatic 
Digital Optical Tracker (RADOT). 


The E-Tape provided recorded histories of 
all pertinent guidance, missile-track, and target- 
track parameters. During the post-mission anal- 
ysis, the recorded target-state estimates were 


used to drive SIS. The missile telemetry data 
provided missile acceleration histories that were 
used primarily to validate missile simulator 
models. The RADOT data provided an accurate 
independent source of missile-state histories, 
particularly during the powered-flight phases. 
On some flights, RADOT provided a valuable 
independent measure of miss distance. 


SPARTAN Intercept Simulation 


The SPARTAN Intercept Simulation (SPASIM) 
is a six-degree~-of-freedom simulation of the 
hardware and software making up the SPARTAN 
intercept subsystem. SPASIM was typically used 
in the Monte Carlo mode to predict SPARTAN 
miss distance and kill-probability performance 
for given intercept points and PAR target-track 
error distributions. 


High-fidelity simulations of SPARTAN and the 
portions of MSR relevant to SPARTAN support 
were provided, The SPARTAN flight dynamics 
models were extensively validated using Meck 
test data.!? All of the significant missile error 
sources were modeled = specific impulse, burn 
time, and weight variations for all three missile 
powered-flight stages; attitude control errors 
during each phase of the missile flyout profile; 
and time reference and atmospheric density var- 
iations. Similarly, MSR missile tracking hard- 
ware models were thoroughly validated using 
Meck test data, and models were provided for the 
key error sources such as radar noise, atmo- 
spheric refraction, and SPARTAN exhaust-plume 
effects. 


SPASIM incorporates high-fidelity models of 
the MSR Weapons Process (MW) guidance and 
missile data processing functions. Guidance 
function models are provided for both free- and 
controlled-intercept guidance modes, and for 
each of the seven major SPARTAN flight phases - 
boost, dive guidance, aerodynamic steering, exit 
attitude control, exoatmospheric coast, jethead 
burn, and post-jethead coast. The missile data 
processing models incorporate the missile-state 
estimation and radar beam-pointing command-~ 
generation functions. Finally, PAR target-track 
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errors were modeled by three-dimensional 
Gaussian distributions, where the means and var- 
iances could be set to values drawn from PAR 
Testbed or TSCS analysis, or in the default case, 
to the DPSPR performance specification values.’ 


ANALYSIS AND KEY RESULTS 


The total SAFEGUARD evaluation program 
consisted of a closely coordinated combination of 
analyses, simulation studies, and test programs 
conducted over a period of several years. The 
areas of investigation covered a wide spectrum, 
resulting in modifications to the design require- 
ments and/or implementation of virtually every 
functional area in the SAFEGUARD System. In 
addition, many other results confirmed that the 
current design was effective in meeting the sys- 
tem objectives. 


Even a brief summary of the total evaluation 
effort is beyond the scope of this document. The 
evaluation activities described here are typical 
of the total program and serve to illustrate the 
emphasis on simulation and the importance of the 
test programs to the evaluation effort. Extensive 
annual reports"-"*provide the details on most of 
the evaluation effort. 


MSR/SPRINT Performance and Characterization 


Many areas of MSR/SPRINT performance were 
investigated. The following discussions cover 
some of the more significant investigations. 


SPRINT Battlespace Utilization 


The SPRINT capability analysis conducted 
early in the evaluation program identified a siz- 
able region of the SPRINT field of fire where 
successiul SPRINT intercepts would be difficult 
to achieve and attainable miss distance would be 
highly sensitive to acceleration uncertainties 
associated primarily with target prediction. 
This region of the field of fire, the 'poor- 
geometry" region, results from the crossing 
angle between the target- and missile-velocity 
vectors being such as to align the miss-distance 
direction (i.e. , the normal to the relative 





velocity vector) along the missile centerline. 
When this geometry prevails, miss distance can 
be reduced only by speeding up or slowing down 
the missile. The poor-geometry region was la- 
beled the "nonlinear" region in contrast to the 
remainder of the field of fire (the "linear" region) 
where achievable miss distance could be esti- 
mated as a linear function of the missile and tar- 
get tracking errors. Subsequent simulations with 
the SPRINT Engagement Simulation (SES) gener- 
ally confirmed the size and shape of the regions. 


Using the system simulation (SAFSIM), inves- 
tigations of the overall. system effectiveness when 
intercepts were constrained to the linear region 
of the SPRINT field of fire indicated that system 
effectiveness was in no sense degraded, but con- 
- versely was somewhat enhanced. Since only in- 
tercepts with a priori high-kill probability were 
planned, thereby eliminating potential second 
shots on the basis of a kill assessment decision, 
the blackout environment (due to SPRINT bursts) 
was reduced, 


As tactical guidance algorithms were devel- 
oped and incorporated in SES, further exploration 
of the linear regions was conducted. As expected, 
due to necessary guidance approximations in the 
real-time program, the nonlinear region was 
slightly expanded. Data generated with SES dur- 
ing the study indicated that the boundary of the 
deadzone was closely coupled to the missile- 
target crossing angle. Zero degrees is the 
"worst case" geometry. Plots of miss distance 
versus crossing angle obtained from the SES re- 
sults indicated that miss distance increased rap- 
idly as the crossing angle decreased below a 
specified minimum. Based on these results, the 
boundary of the deadzone, as implemented in the 
tactical version of interceptor response, is de- 
fined by this specified minimum crossing angle. 


Target-track data gathered in the early portion 
of the Meck Test Program initially characterized 
the expected performance of the wake-track algo- 
rithms employed in the tactical system. That 
knowledge was used to develop (based on MSRSIM 
results) a single-pulse error model to simulate 


the effect of wake-on-track capability. A concur- 
rent analysis conducted with SAFSIM indicated 
that most intercepts at Grand Forks would be in- 
fluenced by wake. Hence, the single-pulse error 
model was incorporated in the SPRINT Engage- 
ment Simulation (SES) to determine the impact of 
the waking environment on intercept capability. 


For each target type, the single-pulse error 
model used a defined region of heavy wake, where 
heavy wake is the expected region of unresolved- 
wake returns. These heavy-wake regions are 
defined in terms of altitude and look angle. 
Within the heavy-wake regions, appropriate 
noise, biases, and transient effects are added to 
the non-wake-error statistics before the track 
data is provided to the track filter. 


The major effect of heavy wake is the intro- 
duction of biases in the filtered target-position 
data. The biases (both range and angle) can vary 
as a function of vehicle type and look angle (angle 
ketween target-velocity vector and radar line of 
sight). 


The SES study of the effect of these biases on 
intercept capability led to the conclusion that 
miss distance was increased when intercepts 
were conducted within the heavy-wake regions. 
Therefore, requirements developed for the 
battle-planning function (SPRINT Interceptor 
Response) accommodated the wake environment. 
Investigations, using the system simulation 
(TACSAF) for a variety of attack conditions, con- 
firmed that adequate battlespace was available 
for almost all intercepts and that the wake con- 
straint produced no overall loss in system 
effectiveness. 


SPRINT Performance Characterization 


The SPRINT intercept simulations described 
earlier were developed to predict the results of 
the SPRINT intercept tests at Meck and to pro- 
vide a tool to characterize intercept capability 
throughout the field of fire. The Meck flight 
tests served two objectives: 


e Provided data for evaluating SAFEGUARD 
System performance to determine if the 


specifications and design produced the de- 
sired results 


e Provided data for reconstructing the test 
with simulations, The reconstruction veri- 
fied the validity of the simulation and/or 
indicated deficiencies in the modeling. 

The measure of intercept capabilities is attain- 
able miss distance. Miss distance, a statistical 
quantity, is caused by uncertainties that can be 
categorized as follows: (1) radar tracking inac- 
curacies, (2) differences between the available or 
achieved interceptor acceleration and that re- 
quired to eliminate predicted miss distance, and 
(3) unpredictable target accelerations. The de- 
pendence of intercept effectiveness on subsystem 
errors made it desirable in the individual flight 
tests to subject the guidance-interceptor-radar 
subsystem to situations where the system uncer- 
tainties stress the intercept conditions. More 
can be learned about the effect of system errors 
from this type of testing, since excessive 
interceptor-acceleration capability will not over- 
come or mask subsystem errors. Consequently, 
the live SPRINT tests were structured to make 
demands on the interceptor capability and guid- 
ance function. The following intercept conditions 
were of interest: 

e@ Inadequate acceleration capability in the 

miss~distance direction caused by low 


dynamic pressure or stressing engagement 
geometry 


Target flight path near the tangent to the 
SPRINT time-of-flight contours 


Intercept shortly after motor burnout 
Long-range, low-altitude intercepts 
Low intercept elevation angles 

Near the vertical missile trajectory. 


SPRINT intercept effectiveness (miss distance 
and intercept-point motion) was demonstrated for 
a variety of intercept conditions during the M-2 
series of flight tests at Meck Island. Data was 
generated for evaluating SPRINT intercept sub- 
system performance and validating the SPRINT 
Intercept Simulation. Integration of subsystem 
elements was proved, and operational character- 
istics of subsystem elements were determined. 


The following major results and conclusions 
are based on mission events and SPRINT Inter- 
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cept Simulation analyses conducted during the 
Meck Test Program: 


e Intercept effectiveness was evaluated, and 
the SPRINT Intercept Simulation was veri- 
fied for 17 collocated and remote launch 
SPRINT Meck test missions. 


@ Observed intercept-point motion for the 
controlled-intercept guidance-mode inter- 
cept points at Meck was always within the 
specified value for nonstressing engage- 

“ment geometry. 


e The SPRINT Intercept Simulation was 
shown to be a highly credible simulation of 
the SPRINT intercept subsystem. 


e Most of the differences between premission- 
predicted and live-mission intercept effec- 
tiveness were due to differences between 
premission and live-mission target-track 
characteristics, 


e The SPRINT Missile Simulation (MISSIM) 
used in SIS was significantly updated as a 
result of observed versus predicted mis- 
sion performance. The key updates were 
missile drag, airframe response, and 
atmospheric models. The final SPRINT 
missile simulation was verified as an ade-~ 
quate model of SPRINT performance. 


e An evaluation of the Missile Site Radar 
Missile Track Simulation (MTRACK) 
showed it to be a very good model of MSR 
tracking accuracy and performance. 


e The utility of first-stage guidance was 
shown by premission simulation analysis 
of Mission M2-22, First-stage velocity 
dispersion is greater than the velocity 
estimation error at the time of command 
computation. 


e The intercept-point bias guidance function 
was deleted from the tactical guidance de- 
sign because of the guidance performance 
stress introduced by the aim-point shift 
during end-game for Mission M2-7 and the 
uncertainty in warhead shadowing. 


e SIS parametric analysis of capability bias* 
performance during the M2-48 premission 
analysis showed that capability bias is 
effective only when an adequate increase 
in prelaunch time of flight is included to 
account for the increased missile flight 
time to intercept. : 


e Intercepts occurring during heavy-wake 
track (M2-18, -38) produced miss dis- 
tance at least on the order of the target 
position estimation bias associated with 
heavy-wake track. 


e The sensitivity of miss distance to inter- 
cept time after wake quench was determined 


*A guidance technique to enhance system per- 
formance in poor geometry situations. 





*% 
y 














during the M2-25 SIS premission analysis. 
Mission M2-27 and -25 verified that inter- 
cepts occurring after wake quench are not 
significantly affected by the target~-state 
estimation occurring at wake quench. 


Target-Track Performance 


One of the most, if not the most critical func- 
tion in the SAFEGUARD System is that of target 
track. The performances of the target-classi- 
fication (threatening or not threatening), target- 
discrimination (RV or non-RV), battle-planning, 
and intercept functions are all critically depen- 
dent upon the quality of data provided on a reen- 
tering object by the target-track function (both 
hardware and software). A major portion of the 
total evaluation effort was devoted to understand- 
ing the sources of target-track error in the MSR, 
the environmental effects on tracking, and the 
performance of the software tracking algorithms. 


An extensive measurement program was con- 
ducted on the MSR at Meck to determine the 
single-pulse range and angle statistics, and to 
validate the modeling employed in the various 
simulations, particularly MSRSIM. Biases ob- 
served between various types of metric data were 
systematically investigated. These included off- 
sets in the data at mode changes, face handovers, 
frequency-to-frequency, and AGC changes. A 
previously undetected amplitude -dependent bias 
was isolated and characterized, and the effect of 
the bias was minimized by adding a phase com- 
mutation technique to the MSR receivers. Posi- 
tion biases between the missile-track and target- 
track modes were identified by simultaneously 
tracking SPARTAN missiles in both the missile- 
track and target-track modes. 


As a result of these investigations, bias ef- 
fects in the MSR were minimized by a combina- 
tion of hardware changes, software corrections, 
and radar alignment techniques. 


The alignment procedures and measurement 
techniques developed during the Meck program 
were applied to the tactical radars at Grand 
Forks. 


Cluttered Environment 


Obtaining high quality track data on an object 
during reentry is made more difficult by two 
potential sources of clutter within that altitude 
regime — target wake and tank breakup. See 
the Classified Supplement for further discussion 
of these clutter sources. 


A major part of the Meck test program was 
devoted to providing the information needed to 
characterize the clutter environment, develop 
track algorithms for operation in the clutter en- 
vironment, and validate the design performance. 


The design of wake track was accomplished 
using the MSRSIM, as was the entry and exit logic 
which uses a combination of a missed-~look test, 
wake-to-body amplitude, and range-extent meas- 
urement, Wake track is basically the use of a 
dynamic threshold to provide a substitute track- 
ing location on the leading edge of the target/wake 
range return whenever the clean-target zero- 
slope is missing. This produces a range meas- 
urement error of time-varying magnitude and 
direction. The target amplitude, wake ampli- 
tude, and length all change during reentry; 
each change is a function of RV type and trajec- 
tory parameters. Thus, the resulting range 
error is a complex function of threshold bias, 
threat type, and trajectory. The angle measure- 
ment is taken at the range of the zero-slope be- 


yond the threshold crossing and is therefore at 


the range of the first wake peak. The measure- 
ment is subject to glint caused by the random 
multiscatter wake. The resulting increased 
angle-measurement standard deviation and angle 
bias in the direction of the wake grow as the tra- 
jectory look angle increases and more of the 
wake enters the affected range resolution cell. 
(The effects of these errors on intercept capa- 
bility were investigated using SES and SAFSIM. ) 
For further discussion, see SPRINT Battlespace 
Utilization. 

The on-going Meck test program was modified 
to provide a series of targets to thoroughly explore 
the performance of the wake-track algorithms. 
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Prior to the availability of the wake-track design 
in the MSR at Meck, digital video recording data 
were obtained for waking targets and used with 
MSRSIM to verify the design. Later in the pro- 
gram, premission simulations using MSRSIM 
were carefully matched against the mission re- 
sults at Meck to improve the design and to verify 
the modeling in MSRSIM. 


MSR/MSDP Traftic Capacity 


Extensive analysis of MSR/MSDP (Missile Site 
Data Processor) traffic capacity during 1971 cul- 
minated in major modifications to the overload 
response in the MSR Weapons Process (MW) 
early in 1972. (See the Classified Supplement 
for additional material on traffic response.) Al- 
though test program schedules did not permit 
full software and system testing of the MW over- 
load response, it is implemented in the software 
as an untested capability. The key features of 
the MW overload response and the traffic capac- 
ity improvements achieved are summarized in 
the Classified Supplement. SAFSIM results on 
SPRINT utilization inefficiencies in the overload 
response are also discussed there. 


Significant traffic performance improvements 
were achieved by functional modifications in four 
major areas: 

e Reduction of track data rates at the onset 

of template overload 


e Revision of overload coast-management 
rules to delay coast initiation until adequate 
data quality.is achieved and to provide 
timely and efficient reacquisition 

e@ Real-time limitation of template pulse 
transmissions to efficiently stay within the 
return generation capacity of a three- 
processor system exerciser 


e Provision of an MSDP overload response 
that gives preference to support of MSR/ 
SPRINT processing over displays, com- 
munications, and SPARTAN processing. 


PAR/SPARTAN Performance and 
Characterization 

Many areas of PAR/SPARTAN performance 
were investigated. Some of the more important 
areas are discussed here. 
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PAR/SPARTAN — Performance Impact of 
Unresolved Target Track 

Refer to Classified Supplement for this dis- 
cussion. 


PAR Performance Characterization 


Data gathered by the PAR while tracking satel- 
lites with the PAR Test Process-(PT) software 
was analyzed to evaluate range and angle meas- 
urement ‘accuracy, radar sensitivity, and PAR 
antenna patterns. 


The radar sensitivity in the search mode was 
characterized as the S/N at a given range on a 
known target at a scan angle of 45 degrees. The 
results indicate that the PAR S/N is approximately 
4 dB better than the hardware specification re- 
quires. 


The peak value, -3 dB widths, and first side- 
lobe levels of PAR antenna sum patterns were 
analyzed. The peak values exhibit a dependence 
with frequency that agrees with the dependence 
obtained from the radar sensitivity analysis. 

The search channel was found to be about 0.5 dB 
more sensitive than the track channel. Analysis 
of the -3 dB widths indicates the achievement.of 
the desired beamwidth, which changes slightly 
(approximately +1 millisine) as the transmission 
frequency and scan angle change. The null of the 
monopulse -difference pattern was analyzed and 
found to be positioned on the tracked target to 
within 0.1 millisine. 

Analysis of PAR measurements of range and 
angle resulted in the identification of seven com- 
ponents of the total absolute PAR measurement 
error: (1) a random component, (2) a bias. that 
depends on the off-axis position of a target, 

(3) a bias that depends on received-signal ampli- 
tude, (4) a bias that depends on transmission fre- 
quency, (5) a bias that depends on sine-space 
location of a target, (6) a bias that depends on 
face-orientation errors, and (7) a remaining m- 
removable bias. The random-error component 
was characterized as a function of S/N and was 
found to be within the system specifications. A 
bias in off-axis angle measurements was detected. 
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It is a complicated function of off-axis position, 
amplitude, and frequency and was seen to change 
from mission to mission, which strongly implied 
alignment and calibration differences. Analysis 
of the alignment procedures used by site person- 
nel led to an upgrading of off-axis track-bias 
performance to tolerable levels. A bias in range 
measurements that depends on the received -sig- 
nal amplitude was detected and characterized, 
and could be removed from the data using an al- 
gorithm in the system software. No significant 
system performance impact arises from this 
bias; thus, the PW change was not made. Sim- 
ilarly, a bias in sin @ angle measurements that 
depends on the location of the target in sine 
space was detected and characterized, and was 
removed from the data by a PW modification. 

A component of the total PAR measurement 
error was attributed to face-orientation errors. 
After correcting the data for all known biases, 
face-orientation angles were estimated so that 
the total PAR measurement error (compared to 
true satellite positions) was minimized. When 
this was done, the total PAR measurement errors 
were within the system specification. 


SPARTAN Performance Characterization 


This section summarizes an evaluation of the 
SPARTAN intercept subsystem performance and 
a validation of the SPARTAN Intercept Subsystem 
Simulation (SPASIM), based on ten SAFEGUARD 
System flight tests that used the SPARTAN inter- 
ceptor. The missions were flown from Meck 
Island, Kwajalein Missile Range, during the time 
from August 1971 to June 1973. 


The objectives of the study presented here 
were threefold: 


1. Assess the ability of the SPARTAN inter- 
cept subsystem to successfully intercept a 
reentry vehicle 


2. Verify that the SPARTAN Intercept Subsys- 
tem Simulation can predict and reconstruct 
the SPARTAN intercept function to a high 
degree of confidence 


3. Using the validated simulation, assess the 
intercept effectiveness of the tactical sys- 
tem throughout the tactical field of fire. 
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Each of these objectives was successfully 
achieved. . Significant conclusions and results 
obtained during the study included the following: 


e Evaluation of intercept effectiveness and 
simulation verification was completed for 
ten missions. 


e The miss distance observed on each mis- 
sion was successfully reconstructed. The 
primary contributor to miss distance was 
shown to be velocity differences between 
the actual delivered third-stage incremental 
velocity for the mission and the average 
performance assumed by guidance in deter- 
mining third-stage ignition time. Radar - 
tracking and telemetered-acceleration data 
gathered during the mission were used to 
determine actual delivered velocity. 


e@ Missile performance models were signifi- 
cantly updated as a result of observed ver- 
sus predicted results for the first six mis- 
sions (i.e., through Mission M2-34). 

After update, the simulation (SPASIM) was 
shown to adequately predict mission results. 


e A moderate degradation in kill probability 
for Mission M2-06 resulted from a 2.2- 
sigma aim-point miss distance. This was 
the largest miss distance on any mission 
and was attributed to the combination of a 
very long coast period after third-stage 
burnout, a large turnaround angle, and a 
missile-state estimation error. Mission 
M2-06 was a low-altitude, long-range 
mission — the longest range mission in 
the test series. 


e@ With the exception of Mission M2-03, the 
actual exit velocity was significantly lower 
than that predicted for the first six flight 
tests (through M2-34), indicating signifi- 
cant inaccuracy in the true missile per- 
formance assumed for SPASIM and guid~ 
ance development. As a result of these 
findings, substantial updates were made to 
propulsive, weight-flow, and aerodynamic 
characteristics of the first- and second- 
stage models. 


e@ Predictions of third-stage orientation sta- 
bility after spinup were verified using 
telemetered -attitude data gathered during 
several missions. 


e The third-stage propulsion characteristics 
used for initial guidance development were 
shown to result in significantly lower per- 
formance than actually delivered. These 
findings resulted in an update to the third- 
stage model. 


e Effectiveness of the forced third-stage ig- 
nition guidance mode is adequate over the 
range of incremental velocity requirements. 
The impact of a forced third-stage ignition 
on intercept miss is accurately character- 
ized by the increased coast time over which 
the velocity error due to the initial turn- 
around maneuver is propagated. 


e In addition to the performance model up- 
dates indicated above, substantial improve- 
ments were made to SPASIM during the 
study. These included additional Monte 
Carlo and third-stage incremental velocity 
printouts to facilitate analysis and model 
verification, and an exoatmospheric short- 
coast option to more accurately model 
turnaround angle for missions where third- 
stage ignition occurs shortly after exit 
and the vehicle has not tumbled. 


e Characterization of the tactical system per- 
formance indicates that aim-point and 
target-miss distance achieved are well 
within the requirements for target kill 
throughout the tactical field of fire. 


SYSTEM TESTING AT MECK ISLAND 


The primary sources for system evaluation. 
were: the Meck System Test Program, Tactical 
Software Conirol Site, and the tactical sites. 
This section discusses the test program as it was 
supported by the prototype Meck System, includ- 
ing the planning and structure of the test program 
and some of the mission results. 


The Meck System was emplaced as a prototype 
installation; more importantly, it provided the 
data for concept verification and evaluated a num- 
ber of system functions in a controlled environ- 
ment, The program was intended to provide 
answers to critical design problems that could 
only be obtained in a live-target environment and 
to validate the software simulations that were 
essential to the success of the SAFEGUARD 
effort. 


The need for a field test program was recog- 
nized in the early phases of development and as 
a result, the installation at Meck contributed to 
early decisions regarding the SAFEGUARD Sys- 
‘tem implementation. 


Objectives 


The overall objectives of the Meck System 
Test Program were to: 


e Provide a near-tactical environment for 
gathering system performance data to aid 
in development and evaluation of the 
SAFEGUARD deployment 
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e Gather S-band radar data for reentry 
physics research 


e Gather data te evaluate concepts for future 
defense systems 


e Gather data for evaluation of tactical and 
experimental target systems. 


Test Requirements 


The System Evaluation Program!" was the 
major source of test requirements for Meck test~- 
ing. These test requirements* were developed 
using the tactical threat and the tactical system 
capability as guidelines. Direct requirements 
from many other agencies, such as the following, 
also influenced the structure of the Meck System 
Test Program. 


e SAFEGUARD System Command [now Ballis- 


tic Missile Defense Systems Command 
(BMDSCOM) ] — primarily responsible for 
the development and testing of the 
SAFEGUARD System 


e SAFEGUARD System Evaluation Agency 
(now TRADOC Systems Analysis Activity) - 
independent evaluation 


e Army Air Defense Command — projected 
user 


e Atomic Energy Commission and Army 
Materiel Command — test requirements 
related to warhead section evaluation and 
demonstration. 

In addition, the following agencies indirectly 
influenced the test program, where possible, to 
support common goals: 

e Advanced Ballistic Missile Defense Agency 


(ABMDA) [now BMD Advanced Technology 
Center (BMDATC)] 


e Defense Nuclear Agency 
Site Defense Program Office 


e Air Force Agencies such as Strategic Air 
Command (SAC) and Space and Missile 
Systems Organization (SAMSO). 


Meck System versus Tactical System 


The capabilities of the Meck System were as 
near tactical as practicable. To support a test 
program starting in early 1970, the Meck System 
designs had to be committed before all of the de- 
velopment work on the various tactical subsys- 
tems was completed. Many of these design deci- 
sions were made in 1967, during the SENTINEL 


Sires 


time frame. At that time, area defense was the 
primary mission and a multisite deployment was 
contemplated. As a result, the test plan for 
Meck initially emphasized area defense. After 
the SAFEGUARD decision, testing shifted to the 
SAFEGUARD mission and was compatible with 
the tactical deployment schedules. 


The Meck System ultimately evolved into a 
prototype SAFEGUARD Missile Site Radar Sys- 
tem, which approximated essential features of 
the tactical system. However, it differed from 
the tactical system in several aspects, 27-30 


e A Perimeter Acquisition Radar was not 
installed at Meck because the benefits to 
be derived did not appear to warrant the 
expenditure. Other radars in the Kwa- 
jalein Atoll could fulfill the acquisition 
role, and prototype testing of the PAR 
could be performed at Grand Forks. The 
absence of the PAR required that the MSR 
be used at greater than tactical ranges. 


e The targets used in system tests at Meck, 
to a large extent, emulated those specified 
in the tactical design threat. However, 
limited system resources (i.e., only eight 
precision target-track channels with three 
data processors installed) and the need to 
obtain data that was well defined required 
that the test targets used be accompanied 
by a minimum of debris. The final sus- 
tainer stage was emplaced to ensure that 
the experiment was conducted in a con- 
trolled environment. 


@ The number of SPRINT and SPARTAN 
launch cells at Meck was limited to four 
and two, respectively, as compared to 
planned tactical complements an order 
of magnitude greater. 


e Only three processors were used during 
Meck testing compared to ten in tactical. 
Computer capacity was further restricted 
by the necessity to perform the nontactical 
function of real-time flight-safety calcu- 
lations. 


e Only two faces were implemented on the 
Meck MSR as compared to the four faces 
on the tactical MSR. The primary threat 
direction of approach at Grand Forks was 
essentially centered on the overlap region 
between two MSR faces. The orientation 
of the Meck faces was such that targets 
launched from Vandenberg Air Force Base 
approached at an angle of about 63 degrees 
from the bisector of the two faces. 


e The Meck installation did not include a 
system similar to the Ballistic Missile 
Defense Center (BMDC); therefore, inter- 
netting concept testing was not possible. 
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e Because of hardware, software, and threat 
environment restrictions, battle-strategy 
testing was not feasible at Meck. Such test- 
ing was left to simulation at the TSCS in 
Madison. 


Test Targets versus Design Threat 


One of the major influences on the test re- 
quirements was the threat against which the Meck 
System should be evaluated. This was dictated, 
in part, by the threats defined for the SAFEGUARD 
System. The Design Evaluation Threat, as out- 
lined in the Data Processing System (DPS) Per- 
formance Requirements for the MW1 process, ! 
was a guide for determining the Meck threat pa- 
rameters. Traffic-related characteristics (i.e., 
rate of delivery of RVs) were not included, since 
it was not considered meaningful to overload the 
Meck System capability with high-performance 
targets at the expense of obtaining useful, con- 
trolled data. Such system stressing was better 
evaluated by means of simulations. 


‘A comparison of the reentry vehicle charac- 
teristics used in the Meck System Test Program 
with the design threat indicated an excellent 
match, even though the basic Meck targets were 
obtained from existing Air Force and Navy inven- 
tories. Although a Fractional Orbit Bomb System 
(FOBS) was considered part of the threat, no 
FOBS-like targets were presented to the Meck 
System, leaving this threat to be evaluated via 
simulations. 


SAFEGUARD Hardware Facilities 
and Functional Capabilities 

SAFEGUARD facilities were emplaced on 
two islands in the Kwajalein Atoll: Meck Island 
and Dleginni Island. Figures 5-2, 5-3, and 
5-4 show the facilities available on these two 
islands. The Meck Island control building 
housed the two-faced MSR and MSDP. The 
launch area on Meck consisted of four SPRINT 
and two SPARTAN launch cells, the respective 
missile assembly buildings, and related ground 
support equipment. Ileginni Island had two 
SPRINT remote launch cells, which were actively 
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used, and two SPARTAN cells, which were built 
in anticipation of the possible inclusion of remote 
launch SPARTANSs in the SAFEGUARD deploy- 
ment. Additional details are contained in the 
Meck Island System Description .3! 


The functional capability of the Meck System 
was incrementally developed and was compatible 
with the planned test program, dictated by the 
deployment schedule and threat assumption. 
During the final tests, the Meck System capability 
was as near tactical as necessary to satisfy the 
evaluation requirements. As the tactical sys- 
tem design evolved, the Meck System was modi- 
fied to reflect this refined capability. Table 5-2 
summarizes the SAFEGUARD System capability 
additions for Meck testing. 


System testing in support of SAFEGUARD 
started in 1970. Prior to that time, subsystem 
checkout and integration was achieved using a 
software package known as M-0. The M-0 proc- 
ess continued to evolve and was used for subsys- 
tem test, calibration, alignment, and mainten- 
ance, independent of the M-1 and M-2 processes 
that followed. 

The initial system software capability (M-1), 
which predated both the SAFEGUARD production 
decision and the evolution of the tactical designs, 
allowed relatively early verification of basic 
concepts and provided preliminary data to support 
basic evaluation objectives. 


The capability of the second version (M-2) re- 
flected the selective refinement and augmentation 
of M-~1 functions in accordance with the 
SAFEGUARD System tactical performance re- 
quirements. The capability additions planned 
for M-2 were implemented in six revision stages, 
defined as M2 Revision 17 (M2-R17) through M2 
Revision 20 (Revisions R1 through R16 were 
implemented in M~1). The first of the M-2 
revision stages was operational in August 1971 
and the last in early 1974. The major functional 
capabilities introduced in M-2 are listed below. 

e M2-R17 — An essentially complete 


SPARTAN intercept function containing 
all major tactical SPARTAN functional 
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capabilities, including external-sensor and 
sequential-state vector inputs to exercise 
the SPARTAN interceptor capability in the 
PAR/SPARTAN mode over its complete 
field of fire. It also included track- 
function capabilities to provide tactically 
representative target tracking for SPARTAN 
engagements. 


@ M2-R18 — Initial SPRINT intercept, track- 
ing, and target-selection function capabil- 
ities for evaluation of SPRINT (collocated 
or remote launch) engagements over the 
complete SPRINT free-intercept guidance 
mode field of fire. It also included tactical 
endoatmospheric target selection based on 
target slowdown characteristics. 


@ M2-R18E — Remaining SPRINT tactical 
functional capability including the con- 
trolled-intercept guidance mode. 


e M2-R19 — Expansion of the track functional 
capability to include tactical track initia- 
tion, and resolved-target wake track for 
aspect angles less than 75 degrees. High- 
fidelity Digital Target Environment Simu- 
lation (DTES) was added to allow accurate 
simulation of heavily waking single and 
multiple targets. 

e M2-R19E — Expansion of the waking-target 
functional capability to include resolved 
target wake track for all aspect angles. 
Also included target selection using the 
Gamma filter. 


@ M2-R20 — Surveillance modifications for 
tactical detection and acquisition perform- 
ance in a dense target environment (Tactical . 
TC-3 search). Also contained target-track 
capability to include unresolved-iarget 
wake track, cluster track, and track- 
through-tank breakup of multiple resolved 
and unresolved targets at all aspect angles. 
Further explanation of M-2 functional capa- 
bility is provided in the SAFEGUARD System, 
M-2 System Functional Requirements and 


Description .¥ 


Data Recording and Reduction Facilities at Meck 


Data gathered with the Meck System was re- 
corded on one or more of the following devices: 
magnetic tape recorder, analog video recorder, 
digital video recorder, brush strip recorder, 
line printer, and teletypewriter. 


Magnetic tape was used for most of the data 
including encoded-radar replies, MSR/MSDP in- 
terface data, intermediate results of calculations 
performed within the MSDP, and timing of signif- 
icant system events. The recording subsystem 
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had ten conventional tape units and two high- 
performance magnetic tape recorders. Data re- 
corded on the latter was stripped and re-recorded 
on the conventional units before it could be re- 
duced on the IBM 360 computer. 


The analog video recorders consisted of four 
16-mm motion picture cameras mounted on four 
dual-sweep oscilloscopes. Each device could be 
assigned to display and film either sum-channel 
or angle-channel video from any of the eight 
target-track channels or two missile-track 
channels. 


The digital video recorder encoded sum- 
channel A~scope video over a selectable 6-kit, 
30-kft, or 60-kft range interval and recorded it 
on magnetic tape with digital identifiers. The 
data could be displayed on a Cathode Ray Tube 
(CRT) in the MSDP or reduced by the IBM 360 
computer to produce various plots and listings. 
This video recorder could record data from all 
eight track channels, and recorded data could be 
reviewed immediately after a mission since no 
film had to be processed. 


The two 120-channel brush strip recorders 
recorded (1) data gathered while testing inter- 
ceptor missiles when they were still in thecells, 
and while sending orders to the in-flight missiles, 
and (2) the timing of significant system events. 
These data were available for immediate analysis. 


Line printers printed summary data on MSDP 
performance and certain significant system events 
upon completion of a test. Hardware malfunc- 
tions detected by fault detection programs were 
printed on teletypewriters. 


Since the MSDP was fully utilized while sup- 
porting software, hardware, and system testing 
(even on a three~shift basis), a second computer 
was used to support data reduction and other non- 
real-time supported software activities. Thus, 
most reduction of recorded data performed at 
Meck was done on an IBM 360 computer with the 
following output devices: three line printers, 
one Gould electrostatic plotter, one CALCOMP 
plotter, and one card punch. 
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Range Support Facilities 


The Kwajalein Missile Range (KMR) range 
support facilities consisted of equipment and 
facilities used to obtain data and determine 
vehicle performance. Telemetry, metric, and 
signature data were acquired by electronic and 
optical tracking systems to evaluate environment, 
control functions, propulsion, airframe, and 
guidance systems on a vehicle. Figure 5-5 gives 
the locations of range instrumentation sites in 
the Kwajalein Atoll. 


The following KMR facilities were used in the 
SAFEGUARD System Test Program: 


Telemetry systems 

Instrumentation transmitters and receivers 
Photo/optical systems 

Meteorological services 

Communications (general) 

Closed-loop television 

Timing : 

Target Track Radar (TTR) at Kwajalein 
Radars at Roi-Namur. 


The KMR radar facilities at Roi-Namur, 
operated by Lincoln Laboratories, are of special 
interest; ALCOR, ALTAIR, and TRADEX radars 
contributed actively as data sources. 


Program Coordination with Other Agencies 


The test requirements received from various 
interested agencies were evaluated and incorpo~ 
rated as appropriate into the Meck System Test 
Program (MSTP). Figure 5-6 depicts the test 
planning cycle that followed and shows the various 
other activities that were included, such as target 
negotiations, resource procurement, and safety 
studies. It also shows the documentation, mis- 
sion certification, and data analysis related to 
the overall Meck System Test Program. 


The Meck System Test Program,** prepared 
by Bell Laboratories, contains a broad summary 
of the entire test program and basic plans for 
each mission, and represents the coordinated 
program of all agencies. Periodic meetings of 
the System Test Working Group provided a forum 
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Figure 5-5. Range Instrumentation Sites in Kwajalein Atoll 
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for test-planning discussions among the inter- 
ested agencies. Likewise, implementation de- 
tails of each test were discussed at periodic 
Test Program Review meetings with those agen- 
cies specifically responsible for test and target 
procurement and implementation. 


The nominal target procurement cycle (see 
Figure 5-7) started when the Ballistic Missile 
Défense Systems Command (BMDSCOM) issued a 
Scope of Work to the Air Force, for ICBM 
Minuteman I and Titan I targets, and to the Navy 
for Intermediate Range Ballistic Missile (IRBM) 
Polaris missiles.35 The Air Force and Navy 
then contracted appropriate studies and the 
necessary target software/hardware. Initial lead 
times were two or even three years. Approxi- 
mately 230 days before the. target mission, Bell 
Laboratories, through either the Army 
(BMDSCOM) or Navy (SPO), issued a Targeting 
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Requirements Confirmation Report, which offi- 
cially finalized the desired targeting and missile 
configuration for a specific mission. 


The SPARTAN and SPRINT interceptor mis- 
siles used in the Meck System Test Program 
constituted a potential hazard to the lives and 
property of inhabitants within the Kwajalein Atoll 
and up to 350 nautical miles outside the Atoll. 
The Flight Safety System (FSS) held this hazard 
probability to an acceptable level. The FSS con- 
sisted of (1) a missile-borne Flight Termination 
System (FTS), a real-time computer program 
within the MSDP Software System that detects a 
potentially hazardous trajectory and starts the 
missile destruction, and (2) the Flight Safety 
Console (FSC), which provides enough data to an 
operator to allow detection of a potential hazard 
and manual initiation of missile destruct. Ih 
addition, mission planning for the Meck System 
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Figure 5-7, Target Procurement Cycle 
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Test Program excluded interceptor missiles 
from unsafe portions of their capability volume. 


As with interceptor flight safety, target flight 
safety was directly concerned with the problem of 
protecting inhabited land masses from target 
vehicles and/or target debris. Determining ap- 
plicable constraints was always an in-line func- 
tion of the test planner in designing system tests. 


Program Planning and Mission Design 


As Bell Laboratories and other interested 
agencies supplied test requirements, planning 
was initiated to incorporate these requirements 
in the test program. A number of factors had to 
be considered in developing an efficient and inte- 
grated plan. Because the Equipment Readiness 
Date (ERD) and Initial Operational Capability 
(IOC) date were fixed, the program completion 
date was inflexible. Asa result, the total num- 
ber of individual missions that could be under- 
taken was clearly limited. Interceptor-evaluation 
requirements were matched to radar-evaluation 
requirements, and jointly dictated the target 


characteristics and trajectory geometry. In ad- . 


dition, the state of system development dictated 
the sequence in which requirements could be ful- 
filled. A feasible program also had to result in 
a minimum expenditure of target and interceptor 
resources. 


As shown in Figure 5-6, individual mission 
designs were documented in the MSTP as early 
as four years prior to the planned mission date. 
This early documentation showed the broad objec- 
tives of the mission and provided descriptive in- 
formation, including target type, planned trajec- 
tory, interceptor type, and intended intercept 
location. 


As individual mission design progressed, pro- 
posals were submitted to the System Test Work- 
ing Group for support of previously unfulfilled 
objectives. Until about eight months prior to the 
mission, more details were added in terms of 
secondary objectives and, in some cases, tertiary 
objectives. Concurrent with the assignment of 
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objectives were flight safety considerations and 
special requirements concerning the geometry of 
each target complex. Target requirements also 
included special payload features, such as 
calibration-reentry spheres. 


Extensive simulations (see System Simulation) 
established that the mission design was compat- 
ible with the Meck System and that reasonable 
assurance of success could be attained. During 
this detailed planning stage, a Manual Interaction 
Simulation (MIS) plan was established for the 
mission. The MIS plan permitted preplanned 
software control of complex sequences of 
display console operations in a mission environ- 
ment, thus exercising the process software in a 
repeatable fashion. This technique, while devel- 
oped initially to provide repeatability in the cer- 
tification environment, was used later during the 
missions to reduce the number of operator ac- 
tions that had to be performed in real time. 


Finally, three months before the mission, the 
Mission Test Specification*® was issued for re- 
view and approval by BMDSCOM and all inter- 
ested agencies. The Meck System Test Program*™ 
was repeatedly updated to contain a current 
account of each of these missions as they devel- 
oped in detail, as well as a current description 
of the total test program. At one month, Bell 
Laboratories at Meck published a Mission Test 
Plan** for each mission to define operational 
details. 


Premission and post-mission documents are 
listed for each mission in Reference 36. 


Test Requirements Memorandum 


A mechanism, established in 1968, permitted 
the initiation of subsystem tests on Meck hard- 
ware, in addition to the more formally sched- 
uled system test activity. To implement such a 
test, the requester issued a Test Requirements 
Memorandum (TRM) describing the test, includ- 
ing data requirements and perhaps an estimate of 
the man-hours and equipment time period. Bell 
Laboratories at Whippany, New Jersey, and at 


Meck Island coordinated the test into the Meck 
activity schedule. Test results and data were de- 
livered to the requester; in some cases, a for- 
mal report was also issued.” 


Later in the program, this TRM procedure 
was expanded to include not only hardware~ 
related tests, but also tests related to specific 
data-gathering tasks. The intent was to maintain 
control and coordination over the many tasks that 
Meck was asked to perform, so that proper sched- 
uling and priorities could be established. Almost 
150 TRMs were logged. Table 5-3 lists some of 
the more significant ones as examples of the 
type of activity performed under this heading. 


Process Verification, Function Integration, and 
Mission Certification at Whippany and Meck 


The complexity of Meck missions and the ex- 
pense of conducting them (target, interceptor, 
and range-support costs) dictated that each 
mission be carefully planned and certified prior 
to its execution. A procedure established at 
Whippany and Meck provided reasonable assur- 
ance that the mission would be successful. Com- 
prehensive dispersion simulations of both target 
and interceptor were performed in the Central 
Logic and Control (CLC) environment. 


The Meck System software was verified, inte- 
grated, and certified prior to a live mission to 
establish a high level of confidence in the mission | 
design and performance of the Meck System, ex- ea 
clusive of interceptor hardware. These tasks 
were undertaken to exercise all portions of the 
Meck System, both software and hardware, that 
would be used during SAFEGUARD missions. 
Live interceptors were not fired during this 
process. 


Figure 5-8 depicts the software development 
cycle beginning with (tactical) system require- 
ments and culminating with post-mission analysis. 
Briefly, separate software functional specifica- 
tions were prepared for each of the major design od 
areas, i.e., Surveillance, Track, SPRINT Guid- ee) 
ance, Sensor Control, etc. From these individual 
specifications, each of the major design areas 
generated software code essentially independent 
of the other major design areas. (Inputs to and 
outputs from each major area, i.e., interfaces, 
were defined early in the design phase.) Each 
major area was responsible for testing its own 
code, i.e., unit testing. When all design areas 
successfully completed unit testing, the code was 
delivered to a process construction team that 
integrated the major blocks into a single software 


Table 5-3 
Examples of Significant TRMs 


TRM-40A,B,C & D 


High -power transmitter tests to determine the cause of waveguide break- 


down under high duty cycle conditions 


TRM-89 


TRM-93 


Track of TRANSIT satellite by MSR, TTR, and ALCOR radars to 
determine biases between data collected by each radar 





Track targets of opportunity, HK-1 and HK-2, to obtain data on 


Minuteman I tank breakup and effect of Titan II fuel on breakup : oy 
phenomenon (HK-2 was also a joint-use mission) : 


TRM-95" 


TRM-97 


TRM-104 and © 
TRM-105 


TRM-110 


Mark 12 reentry vehicles 


safety consideration 


TRM-133 
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Gather data to determine MSR biases between the two faces 
Gather data on SPRINT firing of an aged motor 
Gather additional data on targets of opportunity involving Mark 11 and a3 


Gather Minuteman tank debris data to determine footprint for target 


Gather data on SPARTAN flight test of production motors from IMCO 
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Figure 5-8. Software Development Cycle 


package (process) and placed it under configura- 
tion control. The process was then verified on 
the CLC, the computer for which the code was 
designed, by testing it against a software simu- 


' lation of the target environment and major sub- 


systems (radar, missiles, etc.). This verifica- 
tion was used to regression test all the capabili- 
ties that existed in previous versions of the proc- 
ess and verified proper implementation of any 
new capability. This procedure terminated with 
what was basically an acceptance test for the 
process — a simulation of the most difficult mis- 
sion anticipated during the life of the process. 
The verification validated both the major func- 
tional blocks and the support software (operating 
system, data reduction program, etc.). Upon 
completion of the verification procedure, the 
process was delivered to Meck Island and design 
control shifted to the Whippany Certification 
Group. 


At Whippany, a series of "certification" tests 
tailored to each planned Meck mission was de- 
fined to further exercise the software process in 
a simulated~mission environment, The major 
difference between process verification and mis- 
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sion certification was that verification was used 
to check out the new "nominal" performance of 
the system, while certification was specific with 
respect to each mission and purposely attempted 
to stress the system at the most pessimistic ex- 
tremes of the test in order to expose failure 
mechanisms or otherwise sensitive areas. To 
this end, various target and missile anomalies 
were simulated and the system responses were 
noted. The certification goal was to establish a 
high degree of confidence that the software sub- 
system and mission design would satisfy the mis- 
sion objectives under a wide variety of adverse 
conditions. 


When Meck received the new process, the 
process verification tests were repeated using 
the more complete facility. That is, it was no 
longer necessary to rely on software simulation 
of the MSR and its interfaces since an Analog 
Tactical Environment Simulator (ATES) allowed 
for actual MSR transmission and provided reply 
signals to the IF receiver of the radar on up to 
five discrete targets and two wakes in a beam. 
The Meck process verification was then followed 
by mission certification for each mission. This 


certification consisted of an ATES rerun of the 
tests performed at Whippany, plus additional 
tests designed by the Meck test planners. Again, 
the ultimate objective was to prepare for each 
mission in a manner that would give the highest 
degree of confidence in the ultimate success of 
the mission. Just prior to each mission, a 
performance -prediction estimate was prepared 
delineating the expected performance and out- 
lining the potential problem areas uncovered dur- 
ing the mission-preparation period. 


Finally, the mission was conducted, data re- 
‘duction was accomplished, and the performance 
analysis was undertaken. 


Throughout this verification and certification 
cycle, functional analysis determined the correct 
implementation of the system design specifica- 
tion. A comparative analysis technique was 
used. Independent FORTRAN simulations of the 
primary functions, tracking and guidance, were 
developed and used to generate time sequences, 
order streams, etc., which were then compared 
with similar parameters generated on the CLC. 
These parameters were checked for reasonable- 
ness and consistency between the two simulations. 
A large number of mission-reliability runs were 
performed under the control of the MIS plan (see 
Program Planning and Mission Design). Without 
the problem of human response time, the simula- 
tions were highly repeatable and performance 
discrepancies were easily detected. Discrep- 
ancies were thoroughly investigated and under- 
stood before each mission was conducted. 


The verification and certification procedures 
exposed several design flaws that had to be cor- 
rected in the Meck System and in the tactical 
design. The depth of premission testing was a 
significant factor in the high degree of success 
achieved in the test program. Indeed, the actual 
mission sometimes seemed to be an anticlimax. 
Each mission, of course, was the vital validation 
of the preceding simulations. 
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Premission Radar and Missile Checkout 


In addition to the routine day-to-day system 
checks to assure that the systems and subsystems 
were operating properly, a series of premission 
tests was performed that assured readiness to 
support each mission. In the case of the radar, 
built-in test equipment and a small computer 
capable of providing an order stream to the MSR 
were used for off-line testing. In addition, the 
M-0 process in the MSDP fed a set of specific 
orders to the radar hardware causing the radar 
to react in a predefined manner. This routine 
checked out the radar, the MSDP interfaces, and 
data recording. In addition, signals from an 
antenna on a far-test pole provided off-axis cali- 
bration of the radar and location of failed antenna 
cartridges. Tracking the test pole and calibration- 
quality spheres provided a calibration constant, 
which permitted direct readout of target-radar 
cross section and overall radar system perform- 
ance analysis. The data collected was used in 
Post-Mission Data Analysis (POMDA). 


A variety of physical radar targets deployed 
locally by small rockets, aircraft, or balloons 
was considered for premission and post-mission 
radar calibration. However, only balloon -lifted 
spheres were used extensively as SAFEGUARD 
targets. Most spheres were 12 inches in diame- 
ter and were of radar-calibration quality. They 
were also used to verify system performance 
and to furnish an accurate amplitude reference 
for analyzing recorded data. On the average, 
about 4 spheres were used per week, amounting 
to roughly 1000 over the entire SAFEGUARD 
Meck System Test Program. 


Premission missile checkout included sending 
steering and discrete commands to the in-cell 
missile and noting the response on the telemetry 
monitors. In addition, during the last few sec- 
onds before lift off, the missile underwent go/no- 
go tests to determine readiness to launch. 


Ee 











Mission Summary Information 


SAFEGUARD missions were conducted for a 
variety of test purposes. Some of the missions 
were not part of the original evaluation plan but 


were in response to requests from other agencies. 


Much of these data were useful to the system 
evaluation effort. . 


Post Mission Data Analysis 


Bell Laboratories and its subcontractor, 
Calspan Corporation, expended significant 
effort in performing timely analysis of mission 
data to confirm expected performance or, if pos- 
sible, to permit the identification and correction 
of any system deficiencies prior to the next mis- 
sion. The first step handled at Meck provided a 
preliminary statement of system performance 
for inclusion in 4-hour and 48-hour reports after 
each mission. At CONUS, the data was analyzed 
and presented at a Post Mission Data Analysis 
(POMDA) meeting within six weeks after the mis- 
sion. Representatives of all interested design 
areas attended the meeting. The representatives 
made note of unexpected performance and quickly 
set out to understand, explain, and, if necessary 
correct the problem areas. 


Bell Laboratories/Meck completed their sum- 
mary of post-mission data by publishing a Final 
Mission Test Report®* within 90 days after the 
mission. Calspan Corporation also issued a 
series of post-mission reports: % 

e Mission Data Summary Memorandum, 

which presented MSR data in a series of 


plots to be used as a tool for mission 
analysis and function evaluation 


e Target Data Summary, which summarized 
the results of MSR data relating to the 
target-delivery system performance 


@ Mission Data Analysis Summary Report, 
which summarized the results of the 
primary analysis of MSR performance. 


Mission Description and Results 


The charts that follow summarize the major 
characteristics of the system test missions 
conducted at Meck since early 1970. Table 5-4 
summarizes the concept verification phase of the 
test program during which major SAFEGUARD 
System firsts were achieved. Successful com- 
pletion of these milestones permitted the timely 
commitment of manpower and funds to the devel- 
opment of the SAFEGUARD System as a viable 
concept. 


Table 5-4 
Concept Verification 











M1-1, M1-1A* 













M1-4 
M1-30 


M2-3 
M1-9, M1-9A* 










M1-12 
M1-13 
MI1-8 

M2-7 
M2-7 


SPARTAN 
SPRINT 


Target Type 


Missile Simulated ICBM or 
Type Target IRBM 


M1-7, M1-7A* 
M2-1 


Concept Verification 
Objective 


First SPARTAN launch at Meck 
First live-target intercept 
First salvo 

First two-face IRBM intercept 
First external data intercept 
First in-flight redesignation 


First SPRINT launch at Meck 
First live-target intercept 
First salvo 

First two-face IRBM intercept 
First remote launch 

First remote -launch intercept 































*Where two missions are shown, the first attempt was not completely successful. 
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Mission failures are referred to in several of 
the summary charts. Note that of the 70 mis- 
sions conducted, 12 were listed as failures. Of 
these, four could be attributed to target problems, 
three to SPRINT missiles, three to SPARTAN 
missiles, one to data processing hardware, and 
one to a target-clasgification error due to a 
mission-peculiar attribute. Seven of the eight 
SAFEGUARD-related failures were successful 
migsions in a second attempt. This information 
is summarized in Table 5-5. 


Figure 5-9 presents the broad aspects of 
each of the Meck missions showing the intercep- 


tor type, the target type, the date of the mission, 
and the software configuration in use at the time. 
Mission numbers enclosed in rectangles or ovals 
identify the twelve missions classified as failures. 


Figures 5-10 and 5-11 summarize the location 
of each interceptor flight in the capability volume. 
Interceptors are classified according to target 
type and the two pairs of salvos are identified. 


Table 5-6 summarizes radar evaluation mis- 
sions in M-2, highlighting target type versus 
trajectory geometry. 


Table 5-5 
Summary of Mission Results 








Missions 
Successes 
Failures 
Missions Repeated 
Total Operations 


M1 Series 


13 

12 
5* 
at 

17 





50 

46 
qt 
38 

53 


*M1-1, Data Processing; M1-9, SPRINT; M1-7, Target; M1-14 and M1-14A, 


SPARTAN W/H. 


tM1-1A, M1-9A, M1-7A, M1-14A. (M1-14A counted here, although conducted during 


M2 Series.) 


tyv2~42 and M2-14, SPRINT; M2-20, MSR tank-classification error; M2-44, Target; 
M2-28, no target deployment; M2-245, SPARTAN; M2-36, Target. 


5M2-42A, M2-20A, M2-245A,. 


Table 5-6 
Radar Evaluation with Waking Targets 








M2-31* 


M2-2 
M2-7 
M2-11 
M2-35* 
M2-135* 


M2-22 
M2-24 







Trajectory Geometry 
M2-1 









Fly By 










*Primary objective was to gather data to evaluate response to RV flying through active tank breakup. 


TNo data due to target failure. 


5-32 


Arewwuns UOISSIPY YIOP ‘“G-G a4inbly 








14A37 NOISIAZY JYVM1LAOS ZW NOILVOISIYSA Ld3DNOD 


\—— meet NS6 =z, Gr umZW NX aaLu@Ww X siumew XO ctw XQ tw NN 
%S 





YOLOJA ALVLS-WILNINDAS ASS 

; NOVEAVId 8d 
INIOd 30vdS dS 

sauntivd LaDUVL CD 

sauntivd Noissin [_]4# 





L 
z 
€ 
v 
SNOISSIW 
WWLOL g SNOISSIW 
o 
6E §Z-AS 8Z-AS Ob-AS 9-IW E-AS GE-AS 9-W 8Z-AS 8Z-AS 8Z-AS GZ-AS 9-AW Z-IW IFAS I-AS._- FAS L °° 
8Z-AS 8Z-AS 9-W E-AS OAS Db-AS Z->IW SI-AS SI-AS I-AS z wo 
9-IW SI-AS € 
v SLADYVL 
Gz L 
z S31ISSIN 
NV.LYWdS 
ce L 
| | 
SAOYNOSSY I I \ | € ST TISSIW 
WLOL I ! ! ANIUdS 
t ! 
t 1 | | I | 
sa9unosay 
| | I I ! t 
| | | 


NOINLVOISINSA LdaONOO 





SZ6L bZ6l EL6L cL6l LZ6L OZ6L 










Agro ening ese ay Ne we Meese trent Vee Stee 





~ Oo SPACE POINT 

~ + SEQUENTIAL STATE VECTOR 
® LIVE TARGET INTERCEPT 
o—e +—+ SALVOs 


ALTITUDE —» 


+ M2—43 





TANGENT RANGE —> 


Figure 5-10. Summary of SPARTAN Intercept Locations 
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Figure 5-11. Summary of SPRINT Intercept Locations 
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Targets of Opportunity 


The extensive tracking resources of the MSR 
were attractive to many Air Force programs 
involving reentry-target complexes targeted 
into the Kwajalein Atoll area where reentry 
data could be obtained. These Targets of 
Opportunity (TOOs) were frequently used as 
dynamic targets to checkout the SAFEGUARD 
System at Meck prior to a major system test. 
In addition, they provided targets to satisfy data 
requirements related to specific SAFEGUARD 
engineering tests requested by various design 
groups. Non-SAFEGUARD agencies (such as 
BMDATC and the Air Force) also requested MSR 
data on other targets of opportunity and were 
generally accommodated on a noninterference 
basis. ‘ 


Using Western Test Range (WTR) numbers, 
Figure 5-12 tabulates the targets of opportunity 
(TOOs) that Meck tracked. The shading cate- 
gorizes them according to their status. An 
"engineering test" status was given to TOOs 
where some interest was shown in the data and 
the operation could be conducted on a strict non- 


' interference basis with no hold-status guarantees 


available on the target launch. "Required" status 
was reserved for specific TOOs where a strong 
interest in the data required participation even 

at the expense of rescheduling other activities. 
"Mandatory" status was given to only one TOO, 
which was upgraded to a joint-use target, where 
the SAFEGUARD project was able to influence 
payload and trajectory characteristics and 
obtained guarantees of hold status on the target 
launch. The TOOs identified with a 'none" status 
were used by Meck personnel for system check- 
out with no data obligations. Participation in 
many of the TOOs resulted in useful MSR data 
packages, which were made available to the Air 
Force and other agencies. This figure also 
identifies the TOOs that were used to satisfy 
Test Requirements Memoranda (TRMs). 


System Test Incentive Program Summary 


Since 1971, the Bell Laboratories SAFEGUARD 
contract with BMDSCOM has included System 
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Test Incentives as part of the Scope of Incentive 
Criteria and Evaluation. From the beginning, 

an important ground rule was adopted; no 
“out-of-line" additional effort could be ex- 
pended on a mission because it was incentivized. 
Table 5-7 summarizes the major system test 
events that were incentivized for each fiscal year. 


Miss distance, for incentive purposes, is de- 
fined as the scalar distance between the inter- 
ceptor and the intended aimpoint at the time of 
warhead-command burst. This was considered 
to be the best yardstick for evaluating total sys- 
tem performance, and therefore, played a major 
role in the establishment of the System Test 
Incentive program. Although miss distance 
could be measured by independent sensors, it 


.was decided that the SAFEGUARD Systems cal- 


culation of miss distance using the MSDP would 
suffice for incentive purposes. A series of 
documents* summarized miss distance obtained 
on each mission, using independent sensors on 
most of the live-target intercepts, and tabulated 
these measurements with the MSDP self-scored 
miss distance. 


Miss Distance Measurement Techniques 


The most significant, single indicator of the 
success level for an intercept-test mission is 
miss distance. The contract required that miss 
distance be measured by a means independent of 
the SAFEGUARD System to verify the quality of 
the internal measurement. 


Significant effort was required to select 
acceptable methods for obtaining the independent 
real-time measurements. To be acceptable, 
the methods had to be of acceptable cost, have 
timely availability, and produce measurements 
of adequate accuracy. 


Fortunately, a large background of experience 
was available on which to base the selection of 
methods. The single-path doppler system, 
successfully employed in the NIKE-ZEUS era, 
was initially favored because of its very high 
accuracy and demonstrated reliability. How- 
ever, after completing the initial stages of 


Asewiuung uoissiys Ayuntioddg jo sabe, ‘Z1-G aanbig 


SZ6L pL6l e26l ZL6L L261 











aH 





See SOR 
ete ee TS OS OM 
Peace SS SS) 
Sas 

coLrg L8Ee 
Prectesitetcnctarasd wu 


Prantyeyteceetesseeth a Sag hy SD 
cae ae OS] 





9¢bZ L8€S SOZL 





\ See 

SS 

free 
9 


COE 
CNN 





Wut 
ANON 


AYOLVGNVW 


4 


agay¥iInoaYy N 
N 
41Sal onruaanionafi | 


} 


SNLIVLS VLiVd i 


Ql 


HALYWND Yad SNOISSIN TWLOL 


5-36 











Table 5-7 


Summary of System 


Test Incentives 


Fiseal Major System Mission Come MT Date Contract] Points % of 
Year Incentives Number Points Earned Maximum 


First SPARTAN 
Intercept 


First SPRINT Firing 
at Meck 


First SPRINT 
Intercept 


First SPARTAN Salvo 
First SPRINT Salvo 

Miss Distance May 7, 
First SPARTAN 


Intercept Using 
Tactical Guidance 


First SPRINT Remote 
Launch 


Miss Distance 
Miss Distance 
Miss Distance 


*Date of last mission included in calculation. 


adapting this method to the SAFEGUARD en- 
vironment, the technique was abandoned because 
of cost. The lesser but acceptable accuracies 
of other recourses yielded higher cost effective- 
ness. 


Three techniques for independently measur- 
ing miss distance* were principally employed 
during the series of SAFEGUARD intercept-test 
missions. 


The TTR/ALCOR* "two-radar solution" was 
the principal recourse for the relatively long- 
range SPARTAN intercept missions. In this 


*TTR = Target Track Radar, ALCOR =a member 
of the three-radar complex ‘of the PRESS 
Projectat Roi-Namur. Each is a high-perform- 
ance C-band tracking radar. 
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July 16, 
July 21, 
November 30, 1973* 





August 29, 1970 


October 29, 1970 
December 5, 1970 


December 24, 1970 


January 12, 1971 
March 17, 1971 


1971* 


August 28, 1971 


March 17, 1972 


1972* 
1973* 


Total 


technique, one of the radars continuously tracked 
the target while the other tracked the inter- 
ceptor. Any biases between the radars was 
powerfully determined by simultaneously track- 
ing the target with both radars until it was nec- 
essary to switch one to tracking the interceptor. 
Backup was provided by processing the data ob- 
tained during the interval when both objects were 
contained in each radar beam. 

The TTR or ALCOR "single-radar solution" 
was the principal recourse for the relatively 
short-range SPRINT intercept missions. In 
this technique, the radar tracked the preferred 
reference object (usually, but not necessarily, 
the target) throughout the mission, and re- 
corded range data and angle-off- beam-~center 
data for each radar pulse occurring during the 
interval when the other object was passing 
through the radar beam. 


The network of Recording Automatic Digital 
Optical Trackers (RADOTs) served as a major 
backup for SPRINT intercepts, furnishing photo- 
optical triangulation whenever at least three of 
the eight separately-located instruments were 
not obscured by weather. 


For each intercept mission, all available re- 
sults from primary and backup sources of in- 
dependent miss-distance measurements were 
collected into a coordinated report. This fa- 
cilitated applying the results to the evaluation 
of miss distance as determined in real time 
and recorded by the MSDP of the SAFEGUARD 
System. The independent measurements 
yielded target-to-missile separation versus 
time. Evaluation of the SAFEGUARD function 
required interpretation of success in computing 
the time-of-burst and in delivering the burst- 
command signal to the interceptor. 


INTEGRATION AND DEMONSTRATION 
TESTING AT TSCS AND SITE 


Early in the SAFEGUARD development 
cycle, the problems associated with system 
testing of SAFEGUARD were recognized and 
planning was initiated for the extensive testing 
program that would be required following basic 
function-integration testing of the software pro- 
cesses (MW, PW, and BMDC Weapons Process 
(BW)] at TSCS and later at the tactical sites. 


A SAFEGUARD System Integration and Eval- 
uation Test Plan (SIETP)*® was developed and 
documented, which provided detailed plans for 
accomplishing the following objectives: 


1. Integration of the three sites (PAR, MSR, 
and BMDC) into a smoothly operating 
system and verification of interfaces 


2. Verification of the baseline system-per- 
formance capability against the design 
evaluation threat 


3. Determination of the system-performance 

-- limits, the limiting subsystems, and func- 
tions using extensions of the design evalu- 
ation threat 


4, Evaluation of the system-overload re- 
sponse and degraded-mode capability. 


Objectives 1 and 2 were addressed by a series 
of approximately 12 basic tests. The initial 
tests of the series did not include threat traffic 
but were limited to satellite background, and 
were designed to thoroughly test the system 
interfaces and Command and Control (C&C) subsys- 
tem, including displays and manual actions. The 
remaining tests exercised the total system in the 
three basic system-operating modes (Accidental 
Launch, Pindown Response, and Minuteman De- 
fense), utilizing nominal threat-traffic levels. 


Objectives 3 and 4 were addressed by a series 
of 25 additional tests designed primarily for 
system evaluation, which provided increasingly 
severe system environments (nuclear and clutter) 
to probe the limits of system capability and pro- 
vide increased traffic, well into the system- 
overload regions. These tests, as well as the 
initial series, were to provide an extensive data 
base for validating the system simulations, 
which could then be utilized to extend the evalu- 
ation in whatever direction was appropriate, in- 
cluding variations in the offensive threat. 


In the spring of 1973, the SAFEGUARD pro- 
gram received significant redirection as a re- 
sult of the Strategic Arms Limitation Treaty 
(SALT I) agreements. The limited-defensive ca- 
pability provided by a single site made an exten- 
sive evaluation of system capability less appro- 
priate and the program objective shifted in 
direction to obtaining operational experience with 
deployment, operation, and modification of a 
complex Antiballistic Missile (ABM) or similar 
system. These factors, as well as significant 
adjustments in schedules and funding, called for 
a System Test and Evaluation Program more 
limited in scope and designed to support addition - 
al basic objectives.” 


In addition to supporting the objectives of 
initial system integration and verifying the 
baseline system-performance capability, the 
revised system test program” was structured 
to meet the following objectives: 

e Provide a convenient and satisfactory ve- 


hicle by which the installed netted system 
could be accepted by the Government 


ec 


e Provide a series of major tests which 
would serve as a tool in the post-IOC time 
period for assessing system operability 
a and readiness on a continuing basis [System 
Readiness Verification (SRV)] 


e Provide a limited data base for system 
simulation validation. 

The resulting test program consisted of eight 

S basic tests. As in the previously described pro- 

gram, the first three provided for integrating the 

three sites and verifying the interfaces and 

os Command and Control subsystem. The remaining 

, tests exercised the netted system in the three 

basic operational modes at nominal traffic levels 

a and at nominal threat parameters. 





System Integration Testing 





SAFEGUARD System testing made extensive 
use of the system exerciser subsystem (hardware 
and software), which is a part of the tactical 
configuration at each site, to facilitate assessing 
operability on a continuing basis. The exercise 
subsystem simulates the threat environment and 
me responds to tactical-software engagement planning 
by simulating defensive missiles. An off-line 

_ facility, the SAFEGUARD Threat Action Gener- 
ator (STAG), generates a Site Threat Trajectory 
File (STTF) tape, which provides offensive tra- 
jectories and threat parameters to the system 


gs 
hoe 
fs 


Se 


iL g exerciser. (STAG is a software facility that 
enables simulation of a threat for use by the 
eS system exerciser.) In addition to producing the 


threat tapes, STAG can produce Site Information 
Tapes (SIT), which simulate intersite communi- 
cations. 

The initial integration tests were performed 
first at the TSCS with each software process 
operating in the “local'' mode, i.e., unnetted 
with the rest of the system and with SIT simu- 
lating the other sites. Local-mode tests were 
conducted to establish software sanity and 
correct any software deficiencies that became 
visible. Local-mode tests were followed by 
"netted" tests-with real-time intersite commu- 
: nications (no SIT) and STTF tapes synchro- 

Sos nized so that each site observed the identical 
threat. Extensive recording during the test run, 
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together with off-line data reduction, permitted 
detailed investigation of software problems and 
analyses of functional performance. 


The local and netted tests were run repeatedly 
over a period of several weeks to establish the 
reliability of system response and to ensure that 
most, if not all, software problems had surfaced 
during the runs and had been corrected. Follow- 
ing satisfactory completion of a test sequence at 
TSCS, the identical sequence was repeated at the 
tactical site. 


Acceptance Testing 


Using the system test program as a vehicle 
for Government "acceptance" of the installed 
system imposed a number of specific require- 
ments on the program. The means by which 
these requirements were implemented are illus- 
trated in Figure 5-13 and described in the follow- 
ing paragraphs. 


The planned system acceptance tests, as 
described in the System Integration and Eval- 
uation Test Plan” were reviewed with 
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Figure 5-13. SAFEGUARD System Test Program 


BMDSCOM. The review was conducted to en- 
sure that the tests adequately covered all basic 
system operational modes and threat variations. 
In a number of instances, additions and/or mod- 
ifications to the tests were made at the request 
of BMDSCOM. 


System performance criteria and specific 
performance bounds were established for each of 
the tests. In developing performance criteria, 
the following guidelines were used: 

1. The number of pass/fail criteria were 

minimized by utilizing system-level 


criteria rather than detailed functional- 
performance criteria 


2. Performance bounds were established such 
that a properly operating system should 
pass a given test on a single run 


3. The set of criteria was sufficiently com- 
prehensive that an improperly operating 
system could not go undetected 


4, The pass/fail criteria for each test should 
permit rapid assessment of test success. 


The performance criteria’ [Acceptance 


Test Requirements (ATRs) and System Technical 
VerificationTest Requirements (STVTRs)] were 
subject to Government concurrence and approval 
and were documented along with detailed test 
descriptions in System Test Specifications 
(STSs)."*-** The STS documents were placed 
under formal change control and required 
BMDSCOM concurrence prior to modification. 


In line with the rapid-assessment guideline 
(4 above), a system data-reduction program was 
developed to extract, from the considerable 
quantity of data recorded, that data relevant to 
the system performance criteria. The program 
provided, in a very readable format, the infor- 
mation necessary to verify the pass/fail status. 


The acceptance test criteria were applied 
only to the tests conducted at the tactical site. 
As each of the tests was concluded at the TSCS, 
however, a report and data package was pro- 
vided to BMDSCOM. 


System Readiness Verification Tests 


As indicated previously, the system exer- 
‘ciser subsystem was part of the tactical con- 


figuration at each site to assess system opera- 
bility and readiness on a continuing basis. The 
expected variability in overall system response 
had to be well characterized for any tests to be 
used for readiness testing. The tests utilized 
for integration and system acceptance testing 
met this requirement and, therefore, were 


used for the System Readiness Verification 
exercises. The complexity of the SAFEGUARD 
System and complex interactions between func- 
tions were such that, although the ultimate out- 
come of an exercise in terms of defense level 
was predictable, the path taken through the 
system to achieve that result was quite variable 
and repeatable to only a limited degree. Sta- 
tistical variations, in not only the threat para- 
meters but in functional performance within the 
system, produced variations in performance 
that were totally proper system operation but 
quite unpredictable. 


The system tests were repeated many times 
at TSCS and at site, in addition to being simu- 
lated via the system simulation. Therefore, 

a large data base was available from which to 
draw functional performance bounds for SRV ex- 
ercises. 


To avoid the need for off-line data reduction 
to appraise the results of an exercise, facilities 
were provided in the tactical software to make 
the information readily available. During an ex- 
ercise run, information concerning detection 
tracking, discrimination, and engagement of a 
threatening object was output to a high-speed 
printer. At the conclusion of the exercise, in- 
formation from the weapons process was com- 
bined with system exerciser data, and a "quick 
look" report on engagement results was provided 
via the printer. 


Evaluation and Simulation Verification 


System simulations were used extensively in 
connection with the system test program. Sim- 
ulation results were used in the following ways: 

1. Design of the test scenarios to ensure that 


the desired functional capability was being 
exercised 


Ory 


ay 





¥ 
ft 
p> 
me, 
Eo 
& 


ety, 


METERED 


poets 


rpg 


Bi 


of 
Be 
4 





2. Selection of performance criteria for 
acceptance tests to be indicative of overall 
system response and capability 


3. Fine tuning of the performance bounds to 
ensure that a properly operating system 
would pass and that system deficiencies 
would be detected with high confidence 


Predictions of total system response to a 
particular scenario such that anomalous 
performance could be. quickly identified 
for further analysis 


Indications of the expected variability in 
system response due to relatively low 
probability occurrences and estimates 

of the probability of a particular response 
occurring. 


h 


a 


Item 5 in particular was a major time saver 
with respect to test analysis. The stochastic 
nature of the system inputs (threat) and perfor- 
mance of system functions frequently produced 
results that initially appeared to indicate system 
deficiencies. However, analysis indicated that, 
in most cases, these results were normal system 
response to low probability events. 


MAJOR CHALLENGES AND INNOVATIONS 


Evaluating a test program as complex as the 


- SAFEGUARD System presented many problems. 


Compounding these was the time frame involved. 
Many of the innovative techniques proved to be 
more effective than anticipated. 


Cost Effectiveness of System Evaluation 


Considerable resources were spent on the 
system evaluation organization -— a department- 
size effort in-house, augmented by a subcon- 
tractor simulation development and test data 
analysis effort of approximately equal size. This 
investment led to the development of an in-depth 
analytical capability that otherwise could not 
exist with the tight schedules in the design or test 
organizations. Applying this capability to the 
analysis of system performance led to identifying 
and resolving fundamental system problems that 
required simulation-based analysis owing to their 
complex and interactive nature (e.g., track and 
intercept of waking targets in a tank-breakup en- 
vironment, traffic management, and overload re- 
sponse). Similarly, this detailed understanding 
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of functional performance allowed significant con- 
tributions to the quality and efficiency of the key 
SAFEGUARD test programs — Meck, MSR site, 
PAR site, and TSCS. System evaluation inputs 
were particularly useful in defining a relatively 
small number of test scenarios that stressed all 
key aspects of functional performance, predicted 
system test response through simulation, and de- 
fined data-recording/data-reduction requirements 
tailored to expedite the analysis of known perform- 
ance problems. In summary, the cost of the sys- 
tem evaluation program was well justified by the 
results — a significantly stronger system design 
and higher quality test programs. 


Multisimulation Approach to System Evaluation 


Developing a family of complementary sim- 
ulations rather than a single, large simulation 
embodying both broad scope and extremely de- 
tailed models proved most effective. Separate 
simulations were developed for detailed analysis 
of radar and missile functional problems, in ad- 
dition to the total system simulation. This ap- 
proach allowed a great deal of flexibility in the 
approach to analyzing a particular problem. In 
particular, the long delays in obtaining analysis 
results, which are necessarily associated with 
the use of a single large simulation, were avoided. 


Iterative Approach to Analysis of Complex 
System Problems 

It is most efficient to first analyze a given 
system problem with the simplest model possible, 
then use the insight gained to build an intermediate- 
level simulation to probe key areas further, and 
finally, put the appropriate level of detail into the 
system simulation. This approach significantly 
improves the cost effectiveness of system simu- 
lation development effort by avoiding a uniform 
level of detail in the models — too detailed in 
some areas and not detailed enough in others. 
Most important, it maximizes the timeliness of 
the results by allowing insight based on analysis 
with simple models to be factored into project 
decision-making sooner than would be possible 
with the more detailed simulation models. 


System Exerciser Evaluation 


Insufficient resources were devoted to an 
evaluation of System Exerciser (STAG, EMX, 
and EPX) fidelity and flexibility. This led to the 
relatively late discovery that a few of the key 
elements of system response (such as unresolved - 
target track of PAR) could not be accurately ex- 
ercised with the automatic facility. The result- 
ant crash program of exercise facility modifica- 
tions and “work arounds," while successful, was 
an extremely inefficient use of resources. Fur- 
ther information on the System Exerciser is 
_ given in Chapter 4. 


Requirement for Intermediate Level System 
Design Documentation 


When the focus of the system evaluation ef- 
fort shifted from analysis of the system design 
implied in the DPSPRs to analysis of the actual 
design implementation in MW and PW, it became 
apparent that a level of documentation falling be- 
tween the DPSPRs and the process workbooks/ 
coding specifications was required. It was not 
possible to maintain useful simulation develop- 
ment and modeling schedules when working from 
coding specifications. The required intermediate 
level of documentation, which was provided in 
time to allow the effort to proceed, is best exem- 
plified by the PW Functional Design Requirements. 


Evolution of Meck System Test Program 


Major challenges to the planning and execu- 
tion of the Meck System Test Program related 
primarily to fulfilling the major objectives of 
the program within economic constraints, which 
tended to change with varying funding pressures. 
An adaptive process resulted in which test plan- 
ners established a carefully considered priority - 
ordering of the test requirements so that imple- 
mentation costs could be weighed against value. 
Examples of challenges and innovations that were 
necessary are included in this section. 


At the time the SAFEGUARD Meck System 
Test Program was initiated in early 1970, the 
Meck System test resources (targets and inter- 
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ceptors) planned for use in the test program 
through June 1974 were somewhat greater than 
those actually expended. Table 5-8 compares the 
final program to the February 1970 program. A 
number of factors contributed to these differences. 


The test program was continually scrutinized 
for efficiencies which could result in economies 
to the test program. For example, increased 
emphasis on the use of simulated or taped targets 
for intercept purposes was justified by experience 
and subsequently resulted in the elimination of 
Several targets. 


Experience with azimuth diversity and ex- 
ploration of the MSR face-overlap region using 
IRBM targets demonstrated that these factors 
were not as troublesome as originally feared. As 
a result, Bell Laboratories recommended the 
elimination of several IRBM targets. 


The need for target-tracking tests of actual 
FOBS targets was weighed against development 
costs of FOBS. On the basis of our demonstrated 
ability to conduct realistic simulations, it was 
decided that TSCS exercises against simulated 
FOBS would be more cost effective. 


Table 5-8 


Resource Comparison Between Present 
and 1970 Version of Meck System 
Test Program 


SPRINT 
Meck 
Remote Launch 
Warhead 


SPARTAN 
Meck 


Remote Launch 
Warhead 


ICBM 
Minuteman 
Titan 
FOBS 


IRBM 
Polaris A2 
Polaris A3 


Note: Contingency resources were not included 
in this tabulation 


*Parentheses indicate the warhead totals were 
included as part of the Meck or remote launch 
mission. 
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The development of the tactical system de- 


' pended heavily on the evaluation of Meck test 


data. Timely analysis resulted in a continuing 
re-evaluation of the test program and provided 
additional emphasis on data for suspected prob- 
lem areas. For example, additional target- 
tracking tests were added to better characterize 
tank breakup when it was found that a redesign of 
the system was necessary to perform RV data 
processing through tank breakup. 


Additional economies in the execution of the 
test program were obtained using the operational 
concepts of mission pairing and mission coupling. 
It was found that, by observing reasonable con- 
straints, a missile flight test could be paired with 
a target-tracking mission and we could achieve 
significant savings in the mission preparation and 
operation intervals. This reduced the total re- 
quired man-hours and permitted maintaining and 
even increasing the pace of the test program. 


5-43 


The remote launch station on Qleginni Island 
supported a series of critical tests. The success 
there permitted it to be closed down after calen- 
dar year 1973, approximately 16 months before 
its planned closing. The cost savings justified 
this change even though the more tactical-like 
facilities at Nleginni were preferred for assem- 
bling and launching production SPARTAN mis- 
siles. The remaining production missiles were 
rescheduled for launch from Meck cells, with a 
minor compromise in shipping and handling and 
a significant saving in program costs. 


An exhaustive set of highly repeatable simu- 
lations was made possible through the innovation 
of the Manual Interaction Simulator, which elim- 
inated human response differences from repeated 
runs of the same mission. These mission reli- 
ability runs permitted early detection of non- 
normal system performance prior to each mis- 
sion and thereby resulted in high confidence that 
the mission itself would run as expected. 
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Chapter 6. 


NUCLEAR VULNERABILITY AND HARDENING 


When planning the requirements for an ABM 
system, nuclear vulnerability and hardening are 
important considerations in establishing system 
performance objectives. The need for nuclear 
hardness stems from the system's role of pro- 
viding a defense against offensive missiles which 
carry nuclear warheads through use of its own 
defensive missiles with nuclear warheads. This 
role requires a careful assessment of nuclear 
hardness requirements. Consequently, hardness 
has entered into system design to an increasing 
degree throughout the history of ABM develop- 
ment. 


The need for system hardness was first 
recognized in NIKE-ZEUS, but it was not until 
NIKE-X and subsequent systems that challenging 
hardness requirements were established to pro- 
vide effective defense of the system's own radars 
against multiple attackers. Throughout the evo- 
lution of NIKE-X, SENTINEL, and SAFEGUARD, 
hardware designs were carried out with hardness 
requirements in mind. Over the years these 
requirements changed and became more detailed, 
not so much because of changes in basic system 
objectives and tactics, but more because of a 
deeper understanding of nuclear phenomena. 

By 1968, an-extensive program was getting un- 


‘derway to assure that hardness requirements 


were being met in all building facilities and 
subsystems. That activity continued until the 
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end of the SA FEGUARD development effort. * 

The nuclear hardness requirements for 

SA FEGUARD were finally stated in three nuclear 
environment specifications: one for ground 
equipment! and one for each of the two missiles.2 


ACHIEVING HARDNESS 


The primary consideration for ground equip- 
ment hardness is the effect of enemy warhead 
bursts. An artist's view of the principal nuclear 
effects created is shown in Figure 6-1. Be- 
cause of these effects, a "protection volume" is 


*This chapter concentrates on the vulnerability 
and hardening effort associated with the 
SAFEGUARD Weapon System Equipment de- 
signed by Bell Laboratories. Over the same 
time period, other organizations within Bell 
Laboratories and AT&T Long Lines were study- 
ing the effects of Electromagnetic Pulse (EMP) 
on Long-Haul Communications for other defense 
applications. Between 1969 and 1974, Bell 
Laboratories and Long Lines participated in a 
program established by the SAFEGUARD Com- 
munications Agency (SAFCA) to assess the ef- 
fects of EMP on SAFEGUARD Communications. 
The conclusion reached was that existing common 
carrier facilities with relatively modest changes 
would meet SAFEGUARD requirements in an 
EMP environment.‘ 
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Figure 6-1, Nuclear Weapon Effects on System Facilities 


required (see Figure 6-2) within which enemy 
warheads are not allowed to penetrate because 
an offensive warhead burst within this volume 
will "kill" the defensive installation. To max- 
imize the battle space for engaging enemy war- 
heads, the protection volume should be kept as 
small as possible, although this implies a hard 
defense installation. 


Considerable effort was expended on the 
choice of a protection volume shape and size 
that would represent a good balance between 
battle space and hardness. The size of the 
volume is very much a function of the hardness 
of the system elements (radars, launch stations, 
essential facilities) within the ABM site. The 
contour finally chosen was governed by thermal 
and nuclear effects at high altitude, blast effects 


at intermediate altitudes, and by crater ejecta 
and debris at low altitude. 


For defensive missiles, the dominant hard- 
ness requirements are influenced by fratricide, 
which is the effect of one defensive missile war- 
head burst on a nearby defensive missile in 
flight. Improvements in missile hardness permit 
closer burst spacings and, hence, more effective 
defense in the form of multiple intercepts on a 
single warhead or the capability to engage addi- 
tional warheads. 


Direct verification of nuclear hardness 
through field testing was not possible because 
nuclear detonations in the atmosphere were pro- 
hibited by the Nuclear Test Ban Treaty. Instead, 
hardness verification was primarily done by judi- 
cious combinations of analysis and experiment. 
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Figure 6-2, ABM Site Protection Volume 


Extensive testing was done with shock and vi- 
bration simulators, nuclear reactors, flash 
X-ray facilities, and various EMP simulators. 
In some instances, where none of these testing 
methods would suffice, underground tests were 
conducted with actual nuclear weapons. 


Although some testing and analytical verifi- 
cation were carried out in the early years, a 
significant increase in hardness assessment 
activity began in 1968, and remained at a high 
level until the end of the SAFEGUARD develop- 
ment period. Ground equipment was assessed 
against the following nuclear effects: ground 
shock and vibration, nuclear radiation, air 
blast, thermal radiation, dust, crater ejecta, 
debris, and EMP. The major radar subcontrac- 


tors, General Electric and Raytheon, partici- 
pated in these programs together with Bell Lab- 
oratories. Similarly, missiles were assessed 
against the following effects: radiation from 
neutrons, gamma rays, X-rays, EMP, air 
blast, dust, and thermal radiation. The missile 
subcontractors, McDonnell-Douglas and Martin 
Marietta, participated extensively in these pro- 
grams. 


After the signing of the Strategic Arms Limi- 
tation Treaty and the decision to deploy only one 
site, the final achievement of nuclear hardness 
became somewhat less important than achieving 
other major development objectives. Nonethe- 
less, all the hardness assessment programs 
were carried to completion. 


MAJOR CHALLENGES AND INNOVATIONS 


In the following sections, a number of repre- 
sentative activities are discussed in which con- 
tributions to the technology of hardness assess- 
ment were made on particularly difficult prob- 
lems. These examples were chosen to illustrate 
the scope of challenging work that characterized 
the program. 


Shock and Vibration in Ground Equipment*® 


Three major challenges had to be met to 
ensure the survivability of ground-based equip- 
ment against the shock and vibration environ- 
ments induced by blast and ground motions on 
facilities housing this equipment. In each in- 
stance, some novel techniques were developed, 
whether in the area of nuclear effects criteria 
for a major weapons system, or in the method- 
ology used to verify the survivability of associ- 
ated equipment. 


Environment Definition and Simulation 


Initially, ground motion criteria had to be 
developed, not only in terms of free-field shock 
spectra, but also in the form of ground motion- 
time histories suitable for use in subsequent 
phases of development. The resulting environ- 
ment was defined in terms of free-field shock 
spectra for various depths and two types of 
ground motion-time histories. Two histories 
were required to adequately represent the dif- 
ferent soil conditions likely to be encountered at 
various potential SAFEGUARD sites. 


Next, it was necessary to establish the shock 
and vibration environments to be expected within 
the site facilities (e.g., radar buildings and mis- 
sile silos). This was perhaps the first major 
weapons system project in which these environ- 
ments were established through the use of analy- 
tical models representing the building structures, 
together with some analytical representation of 
the foundation (e.g., soil-structure interaction 
models), in order to calculate the in-building 
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motions. Much basic work was carried out at 
Bell Laboratories, followed by joint efforts 
with the Army Corps of Engineers and their 
contractors, to incorporate these models into 
complex software packages that would permit 
predicting the in-building motion environments. 
The results of these studies were further veri- 
fied by exposing scale models of the buildings 
to blast environments generated by high ex- 
plosives in Operation DIAL PACK, Alberta, 
Canada. 


The final stage involved translating the pre- 
dicted in-building environments into laboratory 
test simulations that would subject the equip- 
ment to the actual environments expected. A 
“synthesized waveform" was developed which 
consisted of a series of damped sinusoidal 
vibrations whose simultaneous application 
yielded a vibration signature that closely re- 
sembled the predicted in-building motion-time 
histories and matched the shock spectrum. 
Coupled with this effort was the need to imple- 
ment testing of equipment response to the syn- 
thesized waveform. A pilot facility was first 
developed at the Bell Laboratories Environ- 
mental Test Installation in Whippany, N.J. to 
handle most of the smaller, lighter equipment. 
For the larger, heavier equipment, a similar 
facility was implemented at Wyle Laboratories 
in Huntsville, Alabama. 


Verification Methodology and Testing 


After developing realistic environments and 
corresponding laboratory simulations, the next 
step was to verify the large number of equip- 
ment units involved. (In the Perimeter Acquisi- 
tion Radar alone, there were 68 different de- 
signs and a total of 991 units.) Ideally, to 
achieve adequate verification, all equipment 
should have been tested. However, by taking 
advantage of equipment modularity (some 
cabinet designs were used repeatedly) and 
similarity, and by careful design of each test, 
a limited test program was formulated. 
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In spite of this effort, some radar units re- 
quired special treatment. These were highly 
complex assemblies considered to be more vul- 
nerable in the operational mode. Several such 
assemblies, weighing up to 10, 000 pounds and 
fully powered with up to 40, 000 volts (see Figure 
6-3 for example), were tested at the Wyle Lab- 
oratories facility. In some cases, while the 
structure of these units was found capable of 
withstanding the tests, certain operational faults 
were uncovered (and later corrected) that could 
only have been found using the high-voltage op- 
erational mode. 


Blast and Thermal Effects on 
Exposed Equipment** 

A major milestone was achieved when the 
Perimeter Acquisition Radar (PAR) antenna 
element's survivability against the combined 
threat of blast and thermal effects was estab- 
lished. This work was noteworthy because it 
was representative of the approach developed to 
verify the survivability of all exposed equipment. 
Similar work was performed with the hardened 
designs of the Missile Site Radar (MSR) antenna 


‘element and antenna support structure. 


The PAR antenna element protrudes some 
9 inches above the ground plane or radar face, 
and is exposed to a complex blast wave pattern. 
By the time the blast wave arrives, the antenna 
element has already been exposed to the thermal 
pulse from the nuclear weapon. The complexity 
of this environment posed a major challenge to 
the engineers who had to simulate exactly the 
combined blast/thermal effects. They were able 
to design a combined program of analyses and 
tests that accurately simulated all the relevant 
effects produced by the combined blast/thermal 
environments of the nuclear detonation. 


The analytical portion of the verification 
program revealed that the thermal pulse could 
produce significant differential expansion of the. 
element's tube structure and even melting of the 
metal. This led to the choice of a special 
metal alloy to be used in the tubular structure 
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that forms the element. Another significant 
conclusion of the thermoelastic analyses was 
that the weather cover protecting the cross- 
shaped radiating elements can be severely 
strained by the differential expansion of the tube 
structure. This latter effect could only be 
verified by subjecting the antenna element to a 
simulated thermal pulse, as was done using the 
Thermal Pulse Simulation Facility at Sandia 
Corporation, Albuquerque, N.M., and then 


- subjecting the same element to a blast environ- 


ment at the DASACON Conical Shock Tube 
Facility, Dahlgreen, Va. (a half-mile long 
shock tube using an explosively-generated shock 
wave). 


Understanding the phenomenology of the 
blast wave interaction with the inclined face of 
the PAR building led to a definition of the type 
of blast tests to be performed at the DASACON 
Facility. Two test configurations were chosen: 
one consisted of a portion of the inclined an- 
tenna face with an array of 40 elements to test 
the element when subjected to a double shock- 
wave pattern, and the other involved a simple 
single shock of higher level which verified the 
element's survivability against the. shock pattern 
that could develop when the incident shock wave 
forms a Mach stem sweeping upslope on the 
inclined face. 


The thermal testing results were valuable 
in the design process in selecting the material 
for the weather cover or cap used to protect the 
cross-radiating elements of the antenna. Sever- 
al materials subjected to the pulse were found 
inadequate, either because they deteriorated 
sufficiently to degrade antenna radiating prop-~ 
erties, or because they produced undesirable 
effects in the adjacent metallic ground plane 
such as increased absorptivity and higher 
temperature on receipt of the incident thermal 
energy. 


The results of these analyses and tests led 
not only to selection of appropriate materials 
for the element metallic structure and the 
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cross-wire weather cover, but also verified 
that the final design of the element would con- 
tinue to transmit and receive even when sub- 
jected to thermal and blast effects. A similar 
program was conducted to verify the hardness 
of other exposed equipment, including the MSR 
antenna elements, MSR antenna support struc- 
ture, and PAR ground plane. 


EMP Hardness Assessment for 
Ground Equipment? 

One of the effects of a nuclear detonation 
is the generation of an extremely high-intensity 
Electromagnetic Pulse (EMP). This pulse is 
capable of inducing currents of thousands of 
amperes on exposed electrical conductors. An 
idea of the magnitude of the disturbance can be 
gained from the fact that EMP from an airburst 
during the Johnston Island tests was believed to 
have disrupted telephone service in Honolulu 
some 600 miles away. 


The SAFEGUARD site is subjected to this 
effect, in varying degrees, from both the deton- 
ation of hostile warheads and the detonation 
‘of its own missiles. 


Very early in the development of SAFEGUARD 


building facilities, a key decision was made, 
based on the advice of the EMP Technical Ad- 
visory Community, to shield all regions con- 
taining sensitive electronic equipment with 
steel, and to use steel conduit to protect elec- 
trical circuits running to the shielded regions. 


This decision circumvented the need to de- 
sign electronic equipment to withstand the free- 
field EMP levels, but left the more limited task 
of providing adequate treatment (e.g., use of 
filters) in the wires, pipes, and apertures 
which must of necessity pass through the building 
shields. 


The implications of this decision were em- 
bodied in the Technical Requirements for Build- 
ing Construction Specification. * Detailed 


*Listed in reference number 9. 


requirements were included for construction 
of the shields as well as requirements for 
attenuation (at most of the frequencies in the 
free-field EMP spectrum) at each shield pene- 
tration from the free-field region. 


This specification in itself did not guarantee 
that the various subsystems would not be up- 
set or damaged by the attenuated EMP-induced 
transients. Consequently, the SAFEGUARD 
System Command (SAFSCOM) required each 
agency to demonstrate by analysis or test that 
its deployed equipment would operate satis- 
factorily in the EMP environment. 


Approach 


In 1968, Bell Laboratories began work on 
the hardness assessment which involved pre- 
dicting the behavior of major subsystems under 
tactical conditions. Of primary importance 
was the need to characterize the effects of EMP- 
induced transients in the various configurations 
of equipment. To provide insight, a number of 
laboratory tests were conducted. These in- 
cluded: 

e Field illumination tests using Parallel 
Plate Transmission Lines (PPTLs) to 
induce transients sufficient to cause up- 
set in the circuits of the Whippany Data 
Processing System (DPS) and the analog 


and digital control circuits of the MSR 
on Meck Island 


Investigation of the upset modes 


Tests using PPTLs to determine the 
coupling loss via DPS coaxial cables 
from a free field to DPS sensitive cir- 
cuits 


e Determining the attenuation characteris- 
tics of filters in the EMP environment 


e Tests of specific items of hardware, such 
as the PAR receiver input circuits, to 
determine their susceptibility to upset or 
damage. 

Assuming that building shields were contin- 
uously welded so that they would be electri- 
cally joint free, it was apparent that EMP 
energy could enter in only one of three modes. 
These are shown diagrammatically in Figure 
6-4 and include: 
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Figure 6-4. Modes of EMP Interaction with Shielded Building 














1. Currents on wires and conduits which 
penetrate the shielded regions 


2. Electromagnetic radiation through aper- 
tures such as doors and ducts 


3. Currents on the shield inner surface in- 
duced by large currents on the outer 
surface. (This process, called diffusion, 
results in voltage differences between 
points on the shield inner surface. ) 

The tests showed (1) that analog equipment 
was three or more times less susceptible to 
EMP transients than digital equipment, (2) the 
significant mode of entry of EMP energy into 
the hardware systems is by coupling to rack 
interconnecting cables, and (3) equipment upset 
in the DPS occurs in the emitter follower Inte- 
grated Circuit Packages (ICPs) which terminate 
the interrack coaxial cables. The characteris- 
tic upset level was determined and empirical 
formulas developed to define the coupling to the 
coaxial cables. Analysis showed the largest 
diffusion effect voltage that could reasonably be 
expected between rack ground points was negli- 
gible with respect to ICP upset level. 


The hardness assessment of Weapon System 
Contractor equipment in the SAFEGUARD 


’ buildings was a straightforward but laborious 


process as follows: 


e Determine the flow path(s) by which EMP 
energy can pass from the outside free 
field to each item of equipment being 
considered. 


e Calculate the magnitude of transient that 
can be expected from the free field on the 
associated penetrators and at the aper- 
tures. Taking into account transmission 
and coupling losses, determine the sum 
total transient to be expected at the 
equipment inputs. 


e By means of careful study (equipment 
review) determine the upset or damage 
level of the equipment in response to the 
sum total transient at its input terminals. 


e Calculate the margin between incident 
transient and upset level. . 
The intricate path of the cabling and the 
complexity of the terminal equipment often made 
it impossible to calculate accurately the EMP 


transients. The method employed to achieve the 
desired results was to establish an upper-bound 
EMP transient that yielded a satisfactory safety 

margin. An upper bound was established by two 
procedures. 


1. Assume the most detrimental condition 
(such as an EMP field parallel to a lead 
exposed to it). 


2. Simplify the mathematics at the cost of 
obtaining an overestimate of the EMP 
effects (by such means as using a short- 
circuit current instead of actual load 
current, neglecting attenuation effects, 
assuming one-to-one coupling, etc. ). 

Because of the conservative EMP/RF inter- 

ference design of the SAFEGUARD System, this 
methodology made it possible to show quite 
rapidly that almost all equipment had a satis- 
factory safety margin. In only a few cases 
were insufficient safety margins found. Where 
these occurred, more precise analyses were 
performed and, if satisfactory results were not 
obtained, hardware redesigns were undertaken 
which later demonstrated adequate margins. 


Because it was clear that system hardness 
would be heavily dependent on the effectiveness 
of the shields, elaborate steps were taken to 
achieve a practical shield design and to control 
the quality of construction. Building designs 
were reviewed and general guidelines for 
shield application were provided, consistent 
with the needs of the architects and engineers. 
Design review meetings were held to answer 
questions on complicated design problems. 
Special inspection techniques such as use of 
magnetic particle inspection (magnaflux) for 
welds, dye penetrant inspection for brazed 
seams or welds, and RF testing of all door and 
hatch closures were instituted. A Western 
Electric site surveillance team followed the 
contractor's installation and inspection opera- 
tions. Many discrepancies were noted by this 
group, but most were resolved by negotiation. 


Others, such as the exothermic welds in the 
PAR Building and the flexible joints in the 
Launch Area Utility Tunnel, required special 
tests to demonstrate acceptability or the need 
for improved design. 


Interagency Intercoupling 


In late 1970, SAFSCOM asked Bell Labora- 
tories to form a special group to do preliminary 
site test planning and to consider two questions: 
(1) Were there any instances where the penetra- 
tions or apertures of one agency could admit 
EMP- induced transients causing unsatisfactory 
operation of other agencies’ equipment? (2) 
Were all of the penetrations adequately treated 
(filtered) ? 


These two tasks were structured as building- 
wide hardness assessments. The approach used 
was similar to that for Weapon System Contrac- 
tor equipment but with a division of effort. 

Each agency provided estimates of the transients 
expected at its penetrations and the upset or 
damage levels of its sensitive equipment. The 
interagency group, located at Bell Laboratories 
in Greensboro, N. C., provided flow path 
drawings and concentrated on identifying the 
points of metallic connection between different 
agencies’ equipment and the configurations where 
detrimental interagency as well as intra-agency 
coupling could occur. 


Bell Laboratories in North Carolina conduc- 
ted experiments to characterize the coupling 
between transient-carrying conductors and the 
coaxial cables which interconnect digital equip- 
ment. This group also participated in the 
Corps of Engineers site test planning, espe- 
cially with respect to tests that would provide 
information related to interagency effects. In- 
formation from the various agencies was com- 
bined with calculations of certain transients and 
with the known losses at the coupling interfaces. 
Then, estimates were made of the lowest mar- 
gin related to the propagation of EMP energy 
from each of the penetrations by metallic path 
or by coupling between metallic paths to sensi- 
tive equipment within the buildings. 
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As a result of the building shields, extensive 
use of conduit, and a strong tendency to segre- 
gate conductors by agency, most estimated 
margins were found to be satisfactory. The 
majority of those which were unsatisfactory in- 
volved intra-agency effects that had already 
been identified by the responsible agency. Un- 
satisfactory conditions resulting from certain 
Weapons System Contractor circuits in SAFCA 
cables and from SPRINT launch preparation 
equipment compartment covers removed for 
maintenance were resolved. 


Launch Stations" 


The launch areas differ from the buildings in 
that they are collections of shielded regions 
interconnected by long underground conduit runs. 
The launch cells are open during and after mis- 
sile launch and the launch preparation equipment 
chambers can be open when a launch station is 
undergoing maintenance. Thus, the open launch 
stations become points of entry for EMP- 
induced currents which can propagate to the 
closed launch stations and connected buildings. 
The magnitude of the currents which enter de- 
pend on the missile position as it leaves the 
cell, as well as the configuration of a launch 
station when opened for maintenance. 


Bell Laboratories subcontractors completed 
hardness assessments taking into account cross 
coupling in the signal conduits as well as the 
various possibilities for transient currents at 
the launch station openings. 


These assessments showed the transient 
level to be unsatisfactory on signal circuits to 
the SPRINT Launch Preparation Equipment 
(LPE) without filter protection. A redesign of 
the signal circuit shield terminations reduced 
the effect to an acceptable level. The assess- 
ments also predicted that high currents would 
be injected on the power feeders to a SPRINT 
launch station undergoing maintenance. A 
change in the maintenance procedure corrected 
the problem. 
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This change resulted from the efforts of Bell 
Laboratories, N.C., who, while working closely 
with the Corps of Engineers on Site Acceptance 
Test No. 5, performed current-injection tests on 
the power system of Remote. Launch Site No. 1. 
The information gathered was used to characterize 
the coupling in the power system. From this 
knowledge it was determined that the transient on 
the feeders to a ready launch station, due toa 
neighboring launch station in maintenance mode, 
would be somewhat higher than the acceptable 
level for satisfactory LPE operation. Since the 
exact safety margin.was unknown, the mainten- 
ancé procedure was changed to minimize the of- 
fending transient. This change also eliminated the 
need for refined analyses of equipment at the Re- 
mote Launch Operating Building and the Electrical 
Distribution Center ends of the power feeders. 


Large-Scale Threat-Level Testing 

In 1969, SAFSCOM, as advised by the EMP 
Technical Advisory Community, directed the 
agencies to begin preliminary planning for a 
SAFEGUARD System EMP Site Test (SEST). 
A wave launcher was envisioned that would be 


- large enough to illuminate the entire Missile 


Site Control Building or PAR Building complete 
with power plant at the design threat level. The 
basis for the EMP community's advice was 
prior experience by the Defense Department 
with weapons systems that failed when they were 
EMP tested. However, those systems were 
designed when the effects of EMP were not well 
understood. Thus, failure resulted from a 
combination of inadequate shield construction 
and inadequate design of the shield penetrations. 


Preliminary planning for SEST was carried 
out in parallel with the EMP hardness assess- 
ment work for the next two years. In 1971, an 
in-depth review of the need for SEST was held. 
By that time, the hardness review of the data 
processing region of the Missile Site Control 
Building had been successfully completed, and 
work on interagency interfaces was well under 
way. Furthermore, it was now evident that 
SEST as originally conceived would be elaborate 
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and expensive. As a result of this review, it 
was decided to drop further planning for SEST 
and rely on the methodology already developed 
for EMP hardness assessment in SAFEGUARD. 


Conduit Problem? 


At the time when the launch area conduit sys- 
tem had just been installed, and when cables 
were first being pulled through the conduits, a 
number of imperfections were discovered through- 
out the installation. Evidence of loose and rusty 
joints was seen, and ground water was leaking 
into some of the conduit runs. Since both the 
EMP hardness assessment and the lightning 
safety analysis depended to some extent on the 
integrity of the conduit system, there was a 
pressing need to reevaluate the "as-built" 
conduit system. Furthermore, there was the 
fear that water might penetrate the’cables and 
cause electrical problems. In addition, freezing 
of water-filled conduits could cause physical 
damage to the cables, thereby degrading electri- 
cal performance. 


An air-pressure testing technique was rap- 
idly conceived to reveal which conduit runs had 
the worst flaws. The technique was refined to 
the point where air-leakage rates for individual 
joints could be measured. This was done by 
isolating short lengths of conduit for pressure 
testing by pulling inflatable bladders into the 
conduit. Eventually, a large percentage of the 
entire conduit system was mapped in this way 
so that air-leakage rates at joints along each 
run were known. Later, this information was 
supplemented by visual inspection of joints 
through the use of a miniature TV camera pulled 
through the conduits. 


Concurrently, laboratory experiments were 
conducted to determine a correlation between 
the air-leakage rate of a faulty joint and the EMP 
leakage to be expected. Other experiments were 
conducted to determine the breakdown charac- 
teristics of faulty joints when struck by lightning. 
Still other experiments showed that water leakage 


and the crushing effect of ice on cables would 
not present serious problems. 


The conclusion reached from these investi- 
gations was that minor defects could be tolerated 
from the standpoint of both EMP and lightning, 
but that larger flaws had to be corrected. Dur- 
ing warm weather in 1973, major flaws in the 
conduits were repaired on an individual basis 
to ensure lightning safety and EMP hardness. 


Dust and Crater Ejecta Environments? 


Detonation of nuclear weapons on or near the 
earth's surface produces considerable airborne 
geologic material ranging from micron-size _ 
dust particles to large boulders. The resulting 
environments are: 

e Dust Cloud - material entrained by the 

rising fireball 


e Crater Ejecta - material essentially thrown 
free of the hydrodynamic flow field 


e Blast-Induced Dust - material scoured 
from the surface by the outwardly propa- 
gating shock front. 

In 1968, Bell Laboratories undertook an ex- 
tensive program to characterize dust and ejecta 
environments and their potential effects on the 
SAFEGUARD System. The scientific community 
was just beginning to concern itself with the im- 
pact of these environments on ICBM and ABM 
systems. Of particular concern were the in- 
flight hazard to missiles due to erosion and im- 
pacts, the degradation of radar signals due to 
scatter and clutter, and the damage to ground 
facilities by impacts, entrainment, and accumu- 
lation. Characterization of these environments 
was made difficult by the Nuclear Test Ban 
Treaty and the fact that none of the previous 
above-ground nuclear detonations had been in- 
strumented to obtain such data. Particularly 
lacking was an understanding of early-time 
(before 5 minutes) dust cloud phenomena and 
crater ejecta impact environments. On the other 
hand, the Air Force Weapons Laboratory (AFWL) 
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had done extensive theoretical work on flow 
fields produced by nuclear bursts. In addition, 
a number of high-energy explosives and a few 
low-yield underground nuclear devices had 
been detonated with the specific objective of 
understanding cratering and ejecta distribution. 


In order to characterize SAFEGUARD dust 
and ejecta environments, a variety of phenom- 
enologies were studied including weapon-earth 
energy coupling, crater mass injection, inter- 
action of dust with hydrodynamic flow fields, 
sweep-up dust sources, and blast-wave dust 
scouring. This led to the integration of a num- 
ber of mathematical and computer models de- 
scribing these phenomena and based on experi- 
mental and theoretical studies. In cooperation 
with the AFWL, extensive computer simula- 
tions were run. This work culminated in a 
description of the nuclear dust cloud for times 
up to 60 minutes in terms of dimensions, mass, 
and particle-number density contours. The 
crater ejecta impact environment was described 
in terms of impact densities and velocities for 
various particle-size ranges. Characteriza- 
tions were also developed for the dust-water 
cloud, crater ejecta cloud, and blast-induced 
dust cloud. These environments were ultimate- 
ly specified in the SAFEGUARD Environmental 
Criteria which formed the basis for evaluating 
the effectiveness of the SAFEGUARD System. 


Debris Environment? 


The strong blast wave from a nuclear deton- 
ation fragments buildings, vehicles, trees, and 
similar objects in its path. The resulting de- 
bris is transported by the blast wave over a 
wide area, representing a hazard to tactical 
facilities. Damage is caused by high-energy 
impacts and the accumulation of debris on ex- 
posed surfaces. 


A debris studies program was initiated at 
Bell Laboratories in 1964 with the primary 











objective of investigating and describing the 
expected debris conditions at ABM sites. Of 
particular concern was damage to missiles be- 
fore launch and possible loss of radar elements. 
At the outset of the program, information on 
these debris effects was very limited. Some 
object-travel distances had been measured and 
a number of photographs taken of structure and 
object damage in certain blast environments 
from previous nuclear tests. Unfortunately, no 
thorough debris data surveys in the blast en- 
vironments of interest had been made. More- 
over, the Nuclear Test Ban Treaty prohibited 
the direct acquisition of data on this phenomenon 
during the debris studies program. 


.To provide data that would properly charac- 
terize debris environments at ABM sites, a. 
variety of experiments were conducted and a 
number of analytical methods introduced. These 
basically involved: 

e ee automobile, and tree fracturing 

ests 


e@ Scaled tests and analytical studies on 
debris transport 


e Expected debris condition predictions. 


The purpose of the fracturing tests was to de- 


termine how buildings, automobiles, and trees 
broke up in nuclear blasts. Fortunately, frac- 
turing does not depend on weapon yield so this 
data could be acquired by participating in the 
high-explosive tests of SNOWBALL, DISTANT 
PLAIN, PRAIRIE FLAT, and DIAL PACK. 
Figure 6-5 shows one of the test results from 
Operation PRAIRIE FLAT. 


Because debris transport at a given over- 
pressure is strongly influenced by weapon yield, 
a mathematical model was developed to simu- 
late debris transport in the Mach region of 
classical blast waves. The results of scaled 
debris-transport tests performed in the high- 
explosive shots compared quite favorably with 
the debris-transport model predictions, pro- 
viding some verification of the model. Finally, 
a procedure was developed that combined the 


empirical fracturing data of a debris source 
with the mathematical model to estimate the 
expected debris conditions of that source. 


The results of this work were used in the 
SA FEGUARD Siting Criteria to specify safe 


. distances for potential debris sources from 


SA FEGUARD missile sites and radars. For 
debris sources that could not comply with these 
criteria, system effectiveness studies were 


' conducted to evaluate the extent to which such 


sources compromised the tactical capability of 
the SAFEGUARD System. A methodology was 
developed that can be used to approximate con- 
ditions for a variety of debris sources relevant 
to SAFEGUARD or other hardened systems. 


Missile Guidance Set 


Power Supply Failures” 


In December 1972 and January 1973, two 
SPRINT Missile Guidance Sets (MGSs) were 
tested at the Aurora Flash X-Ray Facility in 
Beltsville, Md. (See Figure 6-6). The tests 
were expected to provide final confirmation that 
the MGSs would operate properly at the full 
transient radiation level specified for the 
SPRINT environment. Instead, both MGSs 
failed catastrophically at half the specified level. 


Subsequent investigations revealed that tran- 
sistors in a power supply inverter circuit had 
failed due to a breakdown phenomenon. A com- 
prehensive analysis and test program was con- 
ducted to explain the cause of the failures and to 
devise circuit modifications to correct the de- 
ficiency. A circuit modification which included 
changing to another type of transistor was initi- 
ated to correct the problem. 


Further testing at Aurora confirmed that 
MGSs with modified power supply circuits were 
capable of withstanding radiation at the full 
specification level. As a result of experience 
with this problem, improved understanding was 
gained of power-transistor operation in a trans- 
ient radiation environment. 





i(A) Preshot View 





(B) Postshot View . 


Figure 6-5. Frame Building Subjected to 15 psi Overpressure, Operation PRAIRIE FLAT 
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Figure 6-6. SPRINT Missile Guidance Set Being Readied 
for Gamma Radiation Tests at Aurora Facility 


Radiation Effects in Tantalum Capacitors” 


In the course of laboratory testing of elec- 
tronic circuits to confirm predictions of radia- 
tion-induced transients, it became evident that 
tantalum capacitors were producing unexpectedly 
large voltage transients. To obtain a better 
understanding of the phenomena involved, an 
experimental program was undertaken at Gulf. 
Radiation Technology in La Jolla, Calif., under 
Bell Laboratories direction. 


The results of the program gave new insights 
into the radiation-induced transients to be ex- 
pected from tantalum capacitors, and allowed 
output transients from electronic circuits to be 
predicted more accurately. This was of special 
importance in the SPRINT autopilot, where tan- 
talum capacitors were the dominant source of 
radiation-induced transients. In addition, an 
electrical test was developed to screen out tan- 
talum capacitors with abnormal or "maverick" 
transient outputs before they were installed in 
circuits. 
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Internal EMP.in Missiles" 


Internal EMP (IEMP) is produced inside a 
missile as a result of the interaction of gamma 
rays and X-rays with the missile structure. 
Absorption of photon energy in the missile 
structure causes electrons to be ejected from 
internal surfaces and gives rise to replacement 
currents in the structure and to a flow of space 
charge in the internal missile cavities. Both 
the space current and the missile body replace- 
ment currents can cause electrical signals to 
be induced on interconnecting cables which, in 
turn, can induce transients into internal elec- 
tronic assemblies. In simplest terms, even in 
a missile which is well shielded against normal 
EMP, gamma rays and X-rays can produce an 
internal EMP which may lead to failure of 
electronic circuits. 


At the time that hardness assessments on 
the SPARTAN missile were beginning, IEMP 
phenomena were poorly understood and no 
standard techniques were available for 


predicting IEMP transients on interconnecting 
cables within the missile. In fact, it was not 
until 1969 that the existence of an IEMP effect 
became accepted in the nuclear community. 


The principal problem was to make reason- 
able predictions of the transients on intercon- 
necting cables. Once these were available, the 
susceptibility of electronic assemblies could be 
determined experimentally, although this, too, 
proved to be a challenging task. Basic physical 
knowledge was not 2 serious limitation, but 
prediction of cavity pressure, then cavity fields, 
and finally, cable response for actual SPARTAN 
internal surface materials and cavity shapes 
was a formidable analytical challenge. Further- 
more, there was no way to simulate the threat 
environment accurately for experimental con- 
firmation of analytical results, even by under- 
ground nuclear tests. An underground test with 
a full SPARTAN warhead and.at tactical stand- 
off distance was out of the question, and ascaled- 
down test with smaller yield and distance would 
not produce realistic gamma ray and X-ray 
pulse shapes. 


The approach that finally evolved was ana- 
lytic, with analysis confirmed by a‘pumber of 
specialized experimental techniques. The most 
useful of these techniques was missile current 
injection. A full-scale model of the SPARTAN 
third-stage missile configuration was modified 
by adding conducting straps within chosen inter- 
nal cavities, and then cavity currents and re- 
placement currents were made to flow by use of 
an external pulser (see Figure 6-7). This was 
used to confirm the analytically predicted re- 
lationship between cavity currents and replace- 
ment currents and the resulting cable transients. 


Confirmation of analytical predictions was 
also done in an electron beam experiment and 
in the HERMES Flash X-Ray Facility, Albuquer- 
que, N. M. In addition,. some limited experi- 
ments were done in underground nuclear tests. 
In each of these cases, the principal result was 
confirmation of the ability to use analytical 
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techniques already developed to predict the 
results obtained in a particular non-threat 
environment, 


This work was carried out by McDonnell- 
Douglas with close technical direction from 
Bell Laboratories and with the assistance of 
several specialized outside consultants. The 
final result showed that the SPARTAN missile 
was capable of withstanding IEMP effects pro- 
duced by the specified gamma ray and X-ray 
environments. 


The SPRINT IEMP hardness assessment 
began some time after the start of the SPARTAN 
assessment and profited greatly from insights 
gained in the SPARTAN work. SPRINT was also 
shown to be EMP hard. 


SPRINT Autopilot Transients” 


An assessment of neutron and gamma ray 
hardness of the SPRINT autopilot was begun by 
Martin Marietta under Bell Laboratories direc- 
tion in 1969. In the course of the assessment, 
it hecame evident that radiation-induced tran- 
sients in the autopilot could produce transient 
accelerations of the missile which, when added 
to normal maneuvers, might cause structural 
failure of the missile. 


After extensive consideration of a number of 
alternatives, such as circuit hardening, in- 
corporation of circumvention techniques, re- 
duction of order limits, and reduction of speci- 
fied radiation, a decision was made to follow a 
dual path: incorporating selected circuit modi- 
fications and using more realistic hardness 
assessment techniques. The circuit changes 
included: 

e@ Reduction in size of critical capacitors to 

reduce transients 

e Selection of critical zener diodes 


e Electrical screening of tantalum capacitors 
for critical applications to avoid "maverick" 
response to radtation 


e Radiation testing and selection of tantalum 
capacitors for other critical applications 
to limit radiation-induced transients. 
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Figure 6-7. Internal EMP Testing of SPARTAN Missile at McDonnell-Douglas Astronautics Company 


A more sophisticated hardness assessment 


analysis procedure was then developed. This 


procedure could recognize the statistical com- 
bination of transients from various sources 
within the autopilot instead of assuming "worst 
case" combinations. 


Final results from using the statistical an- 
alysis on the modified autopilot showed that 
radiation-induced transients would not exceed 
structural limits. Thus, both SPRINT and the 
SAFEGUARD System were able to maintain full 
effectiveness in the nuclear environment. 


Radiation Effects on 
SPARTAN Missile Structure! 


The SPARTAN missile in-flight nuclear 
environment specification requires the missile 
to survive a stressful radiation environment 
during third-stage exoatmospheric flight. One 
important aspect of the SPARTAN hardness 
evaluation thus became an assessment of the 
effect of energy absorption from radiation on 
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the missile structure. A number of failure 
mechanisms had to be considered including 
shock, spallation, permanent buckling and 
bending, and fracture of rivets and fasteners. 

A complicating factor in the assessment was the 
need to predict the physical state of ablators 
and other structural materials after the heating 
and charring of atmospheric flight. 


Early in the program, a number of discus- 
sions were held with the Atomic Energy Com- 
mission (AEC) to determine what degree of 
structural failure could be tolerated without 
degradation of warhead effectiveness. After 
extensive discussion and evaluation of the 
structural hardness information available at the 
time, a decision was made in 1968 to make a 
change in the warhead ballistic case (the outer 
skin of the warhead section and the supports for ' 
the warhead) to meet the hardness requirement. 


The structural hardness assessment continued 
for several years beyond that point. The assess- 
ment approach consisted of: 


e Laboratory and field tests to characterize 
materials and determine the adequacy of 
analytical methods employed. 


e@ Underground tests in simulated fratricide 
environments. (The most important of 
these were Mint Leaf in 1970 and Diamond 
Sculls in 1972.) 


e Correlation of laboratory, field, and 
underground test data with analysis. 


e Extrapolation of test and analysis data to 
the predicted threat environment to deter- 
mine vulnerability of the missile. 

The assessment program was carried out by 
McDonnell-Douglas under Bell Laboratories 
direction with the cooperation of the warhead 
agencies. The result was that SPARTAN, with 
the redesigned ballistic case, was found capable 
of withstanding radiation levels considerably 
above those called for in the nuclear environment 
specification. 


SPRINT Blast Evaluation” 


An evaluation was performed to assure that 
SPRINT missiles would survive the specified 
fratricide blast encounters. The capability of 
the missile structure was assessed by straight- 
forward analytical and experimental techniques, 
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but assessing the controllability and stability of 
the missile during a blast wave encounter and the 
resulting shock effects on missile components re- 
quired new techniques. 


To assess controllability and stability, a 
special purpose analog computer simulator was 
assembled that incorporated all of the unique 
aerodynamic loadings, control system response 
characteristics, and structural capabilities. The 
simulator showed the effects of long flight dura- 
tions in the low density regions within the blast 
spheres where controllability and stability are 
most affected, especially if the trajectory re- 
quires SPRINT to fly into and then out of a 
blast sphere. This simulation facility was 
successful in demonstrating SPRINT's capability 
during the various segments of flight. 


Shock effects on missile components were 
duplicated by means of large shock tubes at the 
Naval Weapons Laboratory and at Sandia Labor- 
atories. The Sandia Shock Tube (Thunderpipe) 
Facility was enlarged to test a completely assem- 
bled SPRINT second-stage missile. (See Figure 
6-8.) Functional components demonstrated 





Figure 6-8. SPRINT Missile Undergoing Shock Tests at Sandia Laboratories 
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their performance under specification-level 
shock loadings. A principal conclusion drawn 
from the testing was that locally supplied shock 
loadings near each functional component can 
successfully simulate blast loadings on entire 
missile structures. This allowed high-confidence 
blast evaluations to be performed at very low 
cost by making use of readily available shock- 
loading facilities. 


ASSESSMENT RESULTS 


All hardness assessment programs were 
successfully completed. The results of these 


programs showed that all system elements for 
which Bell Laboratories had responsibility 

were capable of meeting the nuclear environ- 
ments stated in the environment specifications. 
The results of the assessment programs are out- 
lined in seven Subsystem Hardness Assessment 
Reports (SHARs).*° These reports also direct 
the reader to further documentation giving de- 
tails of the individual assessment programs. In 
addition to the SHARs, a document was prepared 
that summarizes the lessons learned in the 
Nuclear Vulnerability and Hardening Program.” 
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The Missile Site Radar (MSR) System was de- 
veloped in three distinct phases: Prototype (Meck 
Island Facility - Figure 7-1), Tactical Software 
Control Site (Madison, New Jersey), and the 
Tactical Site (Nekoma, North Dakota - Figure 
7-2). The three sites were installed over a six- 
year period. Installation of the prototype system 
began in late 1967; an MSR receiver and digital 


. equipment group were installed at the Tactical 


Software Control Site (TSCS), as a software and 
partial system checkout facility, in 1971; and in- 
stallation of the tactical MSR site began in 1973. 
Figures 7-3, 7-4, and 7-5 indicate the schedules 
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for the Prototype MSR, TSCS, and Tactical sites, 
respectively. The last major milestone occurred 
on April 1, 1975 [Initial Operational Capability 
(IOC)], when the tactical system was turned over 
for military operation. 


The MSR, as initially conceived, was a short- 
range target and missile tracking radar to be 
used in conjunction with the NIKE-X Multifunction 
Array Radar (MAR).! In this version of NIKE-X, 
two missile tracking radars were to be deployed 
near SPRINT missile farms located some dis- 
tance from the MAR. These two radars were 





- Figure 7-1. Prototype MSR - Meck Island 
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Figure 7-2, Tactical MSR - North Dakota 
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Figure 7-3. Prototype MSR Schedule 
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o Figure 7-4. MSR TSCS Schedule 
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Figure 7-5.. Tactical MSR Installation and Test Schedule 





to contain a large number of tracking channels development program. The proposals were re- 
for relatively short-range target and missile ceived and evaluated, and the contract was 
tracking and, along with the missile tracking awarded to the Raytheon Company, Wayland, 

po capabilities of the MAR, would triangulate the Massachusetts. 


necessary fire power for the proposed NIKE-X 
System. In this deployment concept, the data 

mo processing equipment was to be centrally located 
at the MAR site. 


Prototype study and definition, Phase I, began 
in January 1964 and lasted through May 1964. 
The radar was to be a phased-array type with 


sufficient power output capability to handle both 
The requirements of the MSR, as initially the size and quantity of planned targets and the 

cE conceived, ‘were submitted to prospective con- large number of missiles in track. To meet 
i ; tractors during October 1963 in a request for this power requirement, a new klystron trans- 
quotation on the study phase of the radar's mitting tube was designed, which would provide 
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a combination of bandwidth and output power 
greater than that of any previously available S- 
band tube. To meet the high availability/relia- 
bility requirements, complete channel redundancy 
with high-speed switching was designed into the 
transmitter, receiver, and digital radar control 
equipment.? _ 


The prototype development program, Phase I, 
had been underway one year when the NIKE-X con- 
cept.was revised to provide an autonomous MSR 
with much greater target and missile tracking 
capacity. The revised MSR design was initiated 
in May 1965 and, among other changes, required 
a five-fold increase in average power output. 
After a brief period for redefinition of this larger 
radar system, development began with the goals 
of starting the prototype installation at Meck 
Island (Phase II) in the latter part of 1967, having 
"power-on" by June 1968, and testing SPRINT and 
SPARTAN missiles by June 1969.4 Development 
continued under this concept for one year until 
May 1966 when requirements for additional target 
handling capabilities were placed on the system. 

.With these additional requirements, it was now 
possible for the MSR to handle the entire engage- 
ment and the MAR system disappeared from the 
NIKE-X program.$ 


In October 1967, NIKE-X was renamed the 
SENTINEL System, the MSR prototype design 
was nearing completion, and design of the pro- 
duction version was initiated.’ The only major 
hardware design change at this point, which 
necessitated a new development phase, was con- 
verting the digital radar control from thin-film 
to core memory. All other subsystems were 
modified as required for quantity production, 
and necessary final design work and documenta- 
tion were begun. 


In mid-1971, to facilitate the design and test- 
ing of software and system related interfaces, 
installation of the operating consoles and one 
channel each of the MSR receiving system and 
MSR digital control system was undertaken at 
the TSCS. The MSR equipment design was iden- 
tical to that of the production equipment and was 
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initially used to evaluate MSR test software. 
Testing of the tactical weapons system software 
began in early 1972, with the TSCS continuing to 
support the system checkout and initial operation- 
al phase of the Tactical Site. 


During the latter part of 1968, when design of 
the tactical system was well along, consideration 
was given to increasing the range of the MSR by 
increasing the diameter of the antenna face. This 
proposed redesign, known as the Improved MSR 
(IMSR), was associated with system capabilities 
that might be required at some time in the future. 
Studies were made to define the building modifi- 
cations and antenna support structure that would 
be required to retrofit a tactical MSR system to 
the larger diameter antenna. These studies con- 
tinued until the early part of 1970.’ The building 
was then modified so that the larger antenna could 
be installed. This redesign incorporated a perm- 
anently larger antenna-to-feed horn enclosure 
which could be used with either size antenna, 
thus eliminating the need for future retrofit. The 
smaller antenna, as installed at North Dakota (see 
Figure 7-2), is actually inside a larger annulus 
which can be removed if the larger antenna is 
ever needed. 


Construction for the North Dakota tactical site 
began in the Spring of 1970, installation of equip- 
ment began in late 1972, and power-on was achieved 
for all elements of the system in the beginning of 
1973. With testing of the tactical radar and tac- 
tical software beginning in 1973, the Equipment 
Readiness Date (ERD) was achieved on September 
27, 1974, with Initial Operational Capability on 
April 1, 1975. 


SYSTEM CAPABILITY? 


The 430-acre MSR site at the Stanley R. 
Mickelsen SAFEGUARD complex located near 
Nekoma, North Dakota, is comprised of an MSR 
and the SPRINT and SPARTAN missile farms 
(Figure 7-2). Partially underground, the largest 
structure at this location is the MSR building — 
230 feet square and 123 feet high. The visible 


portion of the building holds the four antenna 
arrays and their associated equipment. Hardened 
to withstand a nuclear blast and its radioactive 

' effects, the concrete outer walls are 4 feet thick, 
slope at an angle of 35 degrees, and rise about 
80 feet above the ground.®" Each of the four 
antenna faces is about 13 feet in diameter and 
contains approximately 5000 phased-array 
elements." 


Operating at a higher average power than any 
existing radar in its frequency band, the MSR, 
with the aid of its associated Missile Site Data 
Processor (MSDP), processes its own autono-~ 
mous target data as well as data from the Peri- 
meter Acquisition Radar (PAR), discriminates 
between warheads and other objects, and.launches 
and guides interceptor missiles on appropriate 
trajectories via an RF command guidance link to 
the SPARTAN and SPRINT missile farms. Based 
on a design concept of two-channel redundancy 
for major subsystems and multiple redundancy 
within the antenna system, the MSR is a preci- 
sion sensor designed for continuous use. (Figure 
7-6 is a functional block diagram of the MSR.) 
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Since the MSR is designed for continuous 
operation, it contains all facilities for maintain- 
ing the electronic apparatus. The redundant 
transmitter, receiver, and digital systems allow 
maintenance work on the off-line channel while 
the radar system is functioning normally using 
the on-line channels. Each of the subsystems 
can be checked in the off-line position to assure 
optimum performance when the off-line channel 
is switched to the on-line position. Facilities 
built into the MSR provide rapid and frequent 
checking of all subsystems while the equipment 
is performing 2 mission function. When 2 fault 
is detected, the channel is switched off-line and 
with the use of additional test signals, the mal- 
functioning chassis is located, replaced with a 
spare, and checked in the off-line position. 


The two output klystrons normally operate in 
parallel. If one of the klystrons malfunctions, it 
is automatically switched off-line where further 
tests can be run. This klystron can then be re- 
placed while the other klystron performs mission 
functions with a 3-dB lower power output. The 
replacement klystron can be activated in the 
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Figure 7-6. MSR Functional Block Diagram 


off-line condition, tested for proper operation, 
and then added in parallel to the transmitting on- 
line tube. 


The 5000 antenna elements in each face are 
replaced from the outside of the building using 
an antenna service vehicle designed for this pur- 
pose.” Very high reliability diodes are used in 
the phase shifters. This, plus the redundancy 
inherent in the large number of array elements, 
results in the need for infrequent maintenance 
of the arrays. Faulty antenna elements are not 
changed until a sufficient number have accumu- 
lated in each face to warrant removing the system 
from service and replacing the elements.“ The 
replacement operation is quite simple and re- 
quires about 2 minutes per antenna element. 


A single transmitter supplies power for all 
four faces by using a high-power face switching 
network consisting of three high-power waveguide 
ferrite switches. The switches allow the trans- 
mitter energy to be shifted from one face to 
another in a fraction of a second. (The receiver 
can be switched from face-to-face considerably 
faster.) Similarly, to allow maximum use of the 
large number of track resources that are avail- 
able for a typical engagement, the antenna beam 
can be switched in a few microseconds from one 
position to a newly calculated position. 


The MSR provides a variety of radar signals 
with varying parameters to accomplish the search 
and tracking functions.’ Chirp and non-chirp 
pulses can be transmitted over a wide bandwidth 
by computer frequency selection. Frequency 
agility simplifies the separation of the large 
variety of acquisition and tracking functions, in- 
cluding the frequencies dedicated for communi- 

_ cations to SPRINT and SPARTAN missiles. 


Operation of the MSR is controlled by the 
MSDP through the radar control interface. 


ANTENNA DESIGN 


The antenna subsystem of the tactical MSR 
provides hemispherical coverage with four 5000- 
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element phased arrays. A single-element Q- 
channel, located adjacent to each array, rejects 
signals received on the array sidelobes.** The 
MSR arrays are space-fed rather than corporate- 
fed; each array uses a separate transmit and re- 
ceive feedhorn located at its focal point. Corpor- 
ate-feed (as used in MAR) was rejected primarily 
due to its mechanical complexities in the dimen- 
sions inherent in a phased-array antenna at 
S-band. 


Each array element consists of a rear horn, 
diode phase shifter, and front radiating element 
containing a beryllia window. As shown in Figure 
7-7, the phase shifter and front element can easily 
be removed from the front of the array for replace- 
ment and repair. Development and manufacturing 
controls of the array components have produced 
a failure rate of less than 2 antenna elements per 
day and a PIN diode rate of less than 100 fits 
(100 failures in 10° component-hours) 7” The 
phase shifter consists of PIN diodes appropriately 
spaced in a coaxial RF structure to provide the 
required 4 bits of phase shift in sixteen 22.5- 
degree segments. The prototype system was de- 
signed with 30 diodes" per phase shifter. The 
development program”! successfully reduced 
the number of diodes to 16 for tactical antenna 
elements, 


The Beam Steering Computer (BSC) of the 
radar control equipment computes the orders for 
each bit in each of the 5000 phase shifters per 
array. These orders are processed by drive- 
amplifier cards, which generate the forward and 
reverse bias for the phase shifter diodes. 


For a space-fed array to be practical, a 
simple method must be used to test each element 
in place. To avoid an RF cable connection to 
each element, a system using the BSC was de- 
vised.” The antenna is pointed at the test pole, 
which radiates an RF signal. To test an element, 
its bits are individually modulated ata 10-kilohertz 
rate by the BSC. The phase modulated signal 
from the element under test and the unmodulated 
signals from all the remaining elements add in 
the receiving feedhorn and are amplified by the 


MSR receiver in the normal way. A sample of 
the receiver IF signal is fed to an antenna test 
set, which recovers the 10-kilohertz phase 
modulation and compares its phase with that of 
the original BSC 10-kilohertz signal. By proper 
a control of each bit, an actual phase measurement 
: can be made. Six phase measurements are made 
on each element to test the four bits of each 
phase shifter. 


Measurement of antenna elements, like other 
test capabilities provided in the MSR, is inter- 
ge: leaved with the normal surveillance functions 
under software control. The antenna element 
test software computes the value of each bit 
from the six phase measurements of the element 


ES and compares the value against acceptance limits. 
a If out-of-limit, the test is rerun at another fre- 
Be quency; if still out-of-limit, the element number 
£ and bit values are "printed out'’ for use in fault 
& location and repair. The antenna element test 
a software can measure ten elements per second. 
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Measurement of the 5000 elements of one array 
face typically requires about 20-minutes elapsed 
time. This antenna element test can be run at 
any time and is initiated manually. The test is 
automatically terminated if the system is re~ 
quired for potential battle engagement. 


The area behind each array and its feedhorn 
assembly is enclosed in an RF chamber for person- 
nel protection. The Meck prototype chambers in- 
cluded an RF absorber, which provided very low 
sidelobe levels. Studies of the clutter levels pre- 
dicted for the tactical MSR site indicated that 
under the expected conditions, a higher sidelobe 
level could be tolerated. As a result, the RF 
absorber was eliminated from the tactical design. 
However, provision was made for mounting a 
high-power absorber material around the periph- 
ery of the arrays to improve the far-out sidelobe 
level by about 6 dB, should it become necessary 2 
Figure 7-8 shows the interior of one of the Grand 
Forks RF chambers. 





Figure 7-7, MSR Array Element Installation 
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A. MSR Feedhorn and Chamber 





8B. MSR Feedhorn and Array 


Figure 7-8. MSR RF Chambers 


Techniques, such as mechanical and optical 
array surveys, accurate location of the receive 
feedhorn on the array normal axis, and use of 
satellite tracks for final correction, have been 
developed to accurately "boresight" each array.¥ 6 
Motion sensors are mounted in the antenna turret 
to detect any long-term structure motion and de- 
rive correction factors to the stored software 
constants pertaining to array orientation. 


RECEIVER DESIGN® 


The basic concept of the MSR receiver and 


signal processing stemmed from earlier 
work done in connection with the NIKE-ZEUS 


Target Track Radar (TTR) and Discrimination 
Radar (DR). In many areas, the MSR receiver 
design was a modification or refinement of the 
earlier designs. For example, the cooled para- 
metric amplifier uses a closed-cycle helium re- 
frigerator based on an Arthur D. Little design 
for cooling the ZEUS TTR maser. The 30- 
megahertz IF limiters and logarithmic amplifiers 
were based on similar designs in the ZEUS DR. 
Some of the 30-megahertz IF amplifier module 
designs in the MSR were unchanged from those 
in the ZEUS DR. 


The MSR receiver consists of two functional 
groups: RF andIF. The RF portion receives 
three signals [sum (2) channel plus two difference 
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channels | from thé antenna comparator. These 
signals are amplified by a multichannel cooled 
parametric amplifier and double-converted to 
the 30-megahertz intermediate frequency. A 
fourth channel, the Q channel, is also imple- 
mented in the RF and IF receivers to provide 
antenna sidelobe blanking! Automatic gain con- 
trol functions are also included in the RF and IF 
receivers to ensure that the received signal is. 
always within the overall receiver dynamic 
range 27.28 


The IF portion continues the four-channel 
processing of the 30-megahertz signals delivered 
by the RF receiver. Figure 7-9 shows the IF 
receiver area. The first portion of the IF group 
employs the matched-filter concept of signal 
processing. High-speed electronic switches pass 
the various waveforms through signal paths that 
have an optimum response to each waveform. 
Significant variations of gain and delay (due to the 
different matched filters) are normalized by in- 
cluding appropriate attenuators and delay sections 
in each matched filter, Residual relative gain 
and phase changes [due to changes in operating 






frequency, Automatic Gain Control (AGC) level, 
etc.] are automatically compensated with binary 
controlled amplifiers and phase shifters.2 After 
the matched filters, the signals are passed 
through logarithmic amplifiers, dechirp networks, 
and equalizers to conventional video signal proc- 
essors to extract target data. Analog-to-Digital 
(A/D) conversion is applied to the signals for 
transfer to the radar control digital circuitry. 


Complete MSR redundancy is utilized in the RF 
and IF receivers to maintain operational capa- 
bility in the presence of any possible fault en- 
vironment. Faults in the RF portion of the re- 
ceiver are detected by amplitude monitoring at 
the inputs of the IF portion of the receiver. These 
monitors respond to test pulse signal inputs to the 
active and redundant channels through directional 
couplers, which precede the TR tube receiver 
protectors. The test pulses are gated into the 
receiver from the RF test set by computer con- 
trol. Improper amplitude values and other faults 
will initiate redundancy switching. Other charac- 
teristics are displayed on control-monitor panels 
to allow manual control and to aid in fault isola- 
tion and calibration. 
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Figure 7-9 IF Receiver 


The IF portion includes monitors that respond 
to these test pulses. The response of the re- 
ceiver to these test signals is used to determine 
the IF channel status. Failure in the on-line 
receiver initiates redundancy switching, after 
which, off-line maintenance is performed on the 
faulty equipment, restoring it to normal operation. 


TRANSMITTER DESIGN 


The MSR transmitter achieves its high power 
output from two parallel high-power klystrons. 
The combined output from these tubes is supplied 
to the space-feed system of the antenna via a 
microwave waveguide system. A space-feed 
system powered from a single transmitter source 
can provide more transmitted power at a lower 
tube cost than a corporate-feed array using 
multiple amplifying tubes. Other advantages 
include fewer total components and the potential 
of higher reliability. 


A. Low Level Transmitter 


Four stages comprise the entire transmitter: 
exciter, buffer, driver, and final. The exciter 
and buffer are known as the Low Level Trans- 
mitter (LLT);” the driver and final stages are 
known as the High Level Transmitter (HLT). The 
solid state exciter generates the required trans- 
mitter frequencies for the HLT, as well as all 
local oscillator frequencies needed by the receiver. 
The buffer is a Traveling Wave Tube (TWT), which 
drives the HLT and also provides the required RF 
test signals. The LLT is completely under the 
control of the radar control equipment, changing 
frequency under computer command.” The vari- 
ous waveforms are generated in the IF receiver 
at 30 megahertz and fed to the LLT for frequency 
up-conversion to RF. Output power and other 
monitors are provided in the LLT to initiate an 
LLT redundancy switch when a failure occurs. 
The LLT equipment is physically located with the 
receiver equipment. Figure 7-10 shows the LLT 
on the left and Radar Monitor and Test Consoles 





8. Radar Monitor and Test Consoles 


Figure 7-10. MSR Low Level Transmitter and Consoles 
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on the right. The LLT output is fed by waveguide 
to the driver stages in the transmitter control 
room. 


The HLT occupies six rooms, comprising a 
major portion of the equipment space in an MSR 
building. Two locked rooms contain the high- 
voltage power supplies. The driver and control 
equipment occupy a room in which all HLT oper- 
ation is controlled and monitored. A specially 
designed room houses the two klystrons mounted 
in large oil tanks. The remaining area contains 
the extensive ancillary support equipment for the 
transmitter, including units involved in the puri- 
fication, filtering, circulation, and heat exchang~ 
ing of the high purity water, dielectric oil, and 
dielectric gas used by the transmitter. 


A matrix of waveguide switches and dummy 
loads provides the redundancy switching capa- 
bility of the driver stages. Either driver stage 
can be connected at its input to the LLT output 
or to the output of built-in test equipment used 
for alignment and trouble location. The output 
of either driver stage can be connected to a 
dummy load or to the final-stage klystron input. 


. Switching is controlled either automatically by 


built-in fault monitors or manually for test pur- 
poses. A specially designed waveguide switch 
provides millisecond switching times. Fault 
monitors in each driver stage detect low power 
output, TWT arcing, low coolant flow, etc. The 
driver high voltage cabinet is equipped with inter- 
locks for personnel protection. A crowbar, using 
a vacuum spark gap, fires in case of TWT arcing, 
interlock operation, or other faults requiring 
rapid removal of high voltage. Opening the 
cabinet door operates the mechanical shorting 
bars to ground high voltage connections. 


The 35-kilovolt power supply for each driver 
occupies a corner of the nearest high-voltage 
power supply room. These solid state, regulated 
power supplies are fed by 480-volt three-phase 
power supplies through conventional switch gear 
adjacent to the high voltage rooms. Control cab- 
inets adjacent to the driver cabinets operate the 
driver stages as well as each final amplifier. The 


built-in test equipment located here includes 

the RF signal generator, RF power meter, 
attenuators, etc. needed to align the transmitter 
and locate faults, as well as power distribution 
circuit breakers and control switches for all 
equipment. All logic required for fault indica- 
tion, crowbar initiation, and system control is 
in a Single cabinet. 


Each high power channel includes a Varian 
Associates VA-144 klystron developed for MSR 
use, This tube has a wide bandwidth high peak 
power output, and a high duty cycle and resulting 
average power output capability. Power varies 
no more than +0.7 dB across the band. The tube 
operates with a 150-kilovolts beam voltage, A 
modulating anode controls the beam pulse. 
Physically, the VA-144 is about 8 feet high.%!2 


As mentioned previously, the klystron is 
mounted in a tank containing 3500 gallons of high 
dielectric-strength transformer oil. Two identi- 
cal tanks are mounted in the klystron room as 
shown in Figure 7-11. The shock-mounted con- 
struction protects the final amplifier equipment 
from damage in a nuclear battle environment. 


All components needed to pulse the modulating 
anode are immersed in the oil tank. The low 
level modulators, in cabinets adjacent to each 
tank, couple to the immersed equipment through 
a pulse transformer, which provides high voltage 
isolation between the external equipment at ground 
potential and the equipment in the tank at -150 
kilovolts, The floating-deck modulator uses two 
Litton L5033 switch tubes, one on the off-deck 
and one on the on-deck, that are cooled by cir- 
culating the tank oil. 


The final amplifier room also contains 14 power 
supplies, seven of which supply focus solenoid 
current to each klystron. A lead shield weighing 
about 2-1/2 tons encloses each klystron to pro- 
tect personnel from X-ray radiation. The room 
is a high bay area equipped with a crane to handle 
the lead shield and klystron when tube changes 
are made. The crane also is used when the 
modulator on-deck or off-deck needs maintenance 
or replacement. 





Figure 7-11. Klystron Room 


Each klystron output connects through a high 
power waveguide to a high-power ferrite circula- 
tor and then to a high-power waveguide switch 
matrix to permit control of the output RF power 
from each klystron. These outputs can be com- 
bined and fed to the antenna, the normal condition, 
or into parallel high-power dummy loads. Ifa 
single channel malfunction occurs, the combining 
hybrid is automatically switched out and the re- 
maining channel is connected directly to the an- 
tenna. For test purposes, the matrix can be 
manually controlled to connect any channel to 
either its own dummy load or the antenna, or 
to connect the combined output into either a 
dummy load or the dntenna. 


The mechanical waveguide switch used to 
handle the transmitter full power output is of 
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special design. It is water cooled and operates 
in less than 100 milliseconds. The high power 
waveguide also is water cooled. Extensive in- 
vestigation took place in the laboratory, using 

a high power resonant ring structure,® to de~ 
termine the mechanism of waveguide RF break- 
down, which occurred in the Meck prototype 
system at high average power levels. In many 
cases, breakdown occurred at the high power 
waveguide flange joints. These had been de- 
signed for the high RF currents involved but 
proper assembly was not always achieved. 
Providing suitable assembly tools and minor 
changes in flange design resolved this. However, 
arcing still occurred at random locations in the 
waveguide. It was noted that the power level at 
which unstable arcs occurred in the resonant ring 
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was a function of the physical length of the ring. 
From these data, it was deduced that the RF 
pulse duration after an arc forms was the control- 
ling factor. Analytical work showed that, at the 
long pulse length and high average power levels 
of the MSR, a random arc would cause. the copper 
waveguide wall to melt.8 This melting created 
copper particulate matter, which would be heated 
by the high average power resulting in more RF 
breakdown and continuous arcing. The system 
remedy was to shut off the RF pulse as quickly 

as possible after an arc formed, preventing the 
generation of more particulate matter. This 
technique is known as “early-off." 


The early-off circuits also protect the trans- 
mitter feed horn window.* Air circulates on 
one side of the window to minimize the deposit 
of dust particles, which could cause an arc. The 
early-off operation prevents damage to the ce~- 
ramic window when an arc does occur. With 
this addition to the transmitter arc detection 
logic, stable operation at maximum average 
power and pulse length was readily achieved, 


In the event of particles either in the wave- 


‘guide or on the transmit feed window, the early- 


off allows the particles to be vaporized by the arc 
without creating additional particles. The effect 
of early-off on the system is similar to that of a 
missing pulse. As missing pulses regularly 
occur from target scintillation, etc., early-off 
has no effect on system performance since the 
software is designed to bridge gaps in data input. 


A bank of three single-pole, double-throw high 
power RF "face" switches is used to connect the 
combined output of the final amplifier stage to one 
of the four antenna faces. One of these face 
switches is shown in Figure 7-12. These switches 
are controlled through the radar control equip- 
ment and consist of four parallel sets of ferrite 
phase shifters. These are fed by splitting hy- 
brids that send one-fourth of the power to each 
set of phase-shifters, The outputs are recom- 
bined through short slot couplers, which direct 
the energy to one of two outputs depending on the 
input phase. Each phase shifter is switched by 
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a suitable modulator connected to its magnet coil. 
The switch has minimum loss and all microwave 
parts are water cooled. , 


Each klystron channel is supplied with the 
required high voltage from a power supply in an 
adjacent room. This power supply is completely 
solid state and uses a three-phase full-wave 
diode rectifier. It is regulated to within 3 per- 
cent by silicon controlled rectifiers in the 4160- 
volt ac supply line. A total of 250,000 coulombs 
of energy is stored in the capacitor bank to supply 
power during the klystron beam pulse. . 


Elaborate safety precautions are used. A 
Kirk key system protects personnel against ex- 
posure to high voltage components, X-ray radia- 
tion, and RF radiation. Fault monitors protect 
the equipment against klystron arcing, wave- 
guide arcing, low coolant flow, high coolant 
temperature, out-of-limit solenoid current, etc. 


Experience with transmitter operation at the 
Meck test site indicates all reliability objectives 
have been met. Tube life data available to the 
end of 1974 indicate the design objective of 
20,000-hours mean life will be achieved for the 
driver TWT and final amplifier klystron. 


After the tactical site transmitter had been in 
operation about six months, the pressure drop 
in the VA-144 klystron collector cooling channels 
increased from a normal 130 psi to as much as 
180 psi. This phenomenon had never occurred 
during the operation at Meck. For seven months, 
an intensive investigation was conducted Dur- 
ing this interval, site operation was maintained _ 
by periodically flushing the collectors with citric 
acid, which removed the copper oxide deposits 
and generally restored the pressure drop to near 
normal. Flushing was needed at intervals vary- 
ing from a few days to two weeks. 


Extensive analysis established that consider- 
able particulate matter existed in the cooling 
water, although the particles were very small. 

A set of 0.45-micron absolute filters was in- 
stalled in the collector cooling line at each 
klystron tank. These substantially reduced the 
particulate matter but did not correct the problem. 


Small quantities of bacteria were also detected. 
To prevent possible growth in the collectors, a 
sterilizing lamp was added to the water purifica- 
tion unit. This also did not change the phenome- 
non, 


Chemical analysis of Grand Forks' high purity 
water versus samples from Varian, Meck, and 
the high power test station at Raytheon's Spencer 
Laboratory (Burlington, Massachusetts) showed 
no essential differences. Impurities were at ex- 
tremely low levels (in parts per million). How- 
ever, only the Grand Forks water showed small 
traces of sulfides. As these were known to 


increase copper oxide formation rates, consider- 
able attention was given to a remedy. Sulfide 
removal was attempted by the temporary use of 
copper pellet scavengers and sulfide removal 
resins but had no effect on the pressure increase. 
An investigation of copper oxide corrosion rate 
versus sulfide and oxygen concentration showed 
no significant rates at the concentrations de- 
tected at Grand Forks. 


-Finally, it was possible to disassemble one 
klystron's collector, which had exhibited the 
pressure drop change at Grand Forks. This 
showed a roughening of the copper oxide in the 





Figure 7-12. Single-Pole, Double-Throw High-Power RF “Face” Switch 


7-14 


Canary 
sete ash 





conical region. Earlier calculations had shown The radar control function is implemented by 
that such roughening could cause the pressure equipment called the Digital Control Group 
F drop increase. Analysis of the oxide on the (DCG Like the receiver and the transmitter, 
: Grand Forks collector and on a collector that had the major portion of the DCG is redundant, with 
operated only at Meck showed no chemical differ- each portion called the Digital Control Unit 
o ences. It was postulated that the oxide formed (DCU). Besides the two DCUs, the DCG in- 
in the normal way but was roughened by hydraulic cludes the Switch Rack and the Beam Steering 
differences. _ . Computer (BSC). The Switch Rack monitors 
Bi Tubes were subsequently flushed at Grand each DCU output and performs redundancy 
: Forks using sulfuric acid to assure more complete switching when a fault occurs. 
removal of oxide. The static pressure on the The DCG uses standard SAFEGUARD logic 
f° collector was also increased by throttling on the and has eleven logic racks and eleven power 
: return line, Since then, no further pressure supply racks. Some of the DCG logic racks are 
drop increase has occurred, It is believed that shown in Figure 7-13. Each DCU has three 
at low pressure, incipient cavitation begins caus- racks: input, output, and control. The BSC 
ing rough erosion. Once started, the roughening has two control racks and three register racks. 
propagates, causing a pressure drop increase. . The Switch Rack completes the complement. 


“ At a higher static pressure, cavitation does not 

: occur, precluding roughening of the oxide. Meck 
had always operated at the higher static pressure, 
hence the phenomenon was never seen there. 


RADAR CONTROL DESIGN 


The MSR is controlled by the Missile Site 
Data Processor (MSDP). The MSR Weapons 
ou: Process (MW) software specifies the mode, fre- 
quency, antenna beam direction, transmitter 
power level, waveform, range gate width, min- 
imum range, type of data needed, etc., for 
every transmission and every receiving 
interval 7" 


The function of the radar control equipment is 
to accept and store, until called, 68-bit words 
from the MSDP containing the desired action 
a and the time it is to be taken. At the specified 
i time, the words are decoded and the necessary 
control signals are generated and sent to the 
transmitter, receiver, and antenna. The re- 
ceiver output is transformed from analog to 
digital signals and sent to the radar control 
equipment,. where it is formatted with related in- 
formation and stored to be transferred to the 
MSDP when requested? 








Figure 7-13, Digital Control Group Logic Racks 
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About 110,000 integrated circuit packages are 
used in the entire DCG. 


To steer the antenna, the phase setting of each 
phase shifter must be calculated from the steer- 
ing angle instructions. This is accomplished by 
the BSC,“ which has two sets of registers; one 
holds the array in its last position while the 
second is being set for the next position. When 
the beam is to be repointed, the new phase shifter 
values are "jammed" from the second register to 
the first one. The beam steering calculation not 
only determines settings for the desired beam di- 
rection, but also corrects for the fact that the 
wavefront at the array face from the feedhorn is 
spherical. The constants for this correction are 
stored in a wired memory, which is part of the 
BSC. Calculation primarily involves increment- 
ing a fixed phase shift from element to element. 
This is accomplished in functional logic blocks 
called accumulators. The element phase values 
therefore ripple through the registers as they are 
calculated. At jam time, all values are simul- 
taneously transferred to the output registers. 


The phase shifter diodes require 250-volts re- 
verse bias or 150-milliamperes forward current. 
Each phase shifter has a drive amplifier to con- 
vert from the logic level of the registers to the 
diode bias level. Ina four-face system, each 
face has a full complement of 5000 drive ampli- 
fiers. All four sets of drive amplifiers are fed 
in parallel from the output of the BSC. A face- 
select indication provided by the BSC fans out to 
all drive amplifier cards, enabling only the face 
desired. Figure 7-14 shows one of the 144 drive 
amplifier racks. 


Radar instructions in the form of groups of 
four or five 68-bit words flow from the MSDP to 
the input memory of each DCU where they are 
stored until instruction time. The words are 
then subdivided by the input controller and fed 
to the various other controllers. Four control- 
lers convert the digital information into pulses 
at the proper time to control analog parts of the 
MSR (i.e., the transmitter, IF receiver, video 


receiver, and test controllers). The BSC 


controller sends the instructions in digital form 
to the BSC for its calculations. 


The set of output pulses from each DCU to the 
other portions of the MSR are continually com- 
pared in the Switch Rack. In case of a noncom- 
pare, software tests identify the faulty DCU. 
Redundancy switching takes place as needed. 


The data output of the receiver is in digital 
form from the encoders. Because receiver data 
must be taken in real time as radar return sig- 
nals occur, it is loaded into temporary storage 
(Receiver Data Buffer) for a brief time until it 
can be transferred in blocks to the output mem- 
ory. The Output Memory Controller performs 





Figure 7-14. 


Drive Amplifier Racks 




















this transfer as well as transfer of data from the 
Output Memory to the MSDP when requested. 


The DCG, therefore, is a wired logic decoder 
for input data and a formatter for output data. 
There are, of course, a number of important test 
capabilities. it has parity checking in critical 
places and also continuously monitors each DCU 
operation. Insummary, the DCG provides the 
interface between the Data Processor and the 
analog parts of the radar. It is redundant and 
automatically switches when a fault occurs. It 
is maintained by test software via a control 
console provided for that purpose. This test 
software also provides monitoring and trouble 
location for the entire radar equipment. 


DCG testing, overall MSR fault indication, and 
continuous performance checking are accomplished 
by test software included in the Weapons Process. 
This software is controlled from the Radar Moni- 
tor Console.” Three classes of tests are made: 
Class A, Class B, and Class C."44 


Class A tests create test pulses, which run 
continuously under all system operating condi- 
tions. These cause the hardware monitoring 
equipment in the receiver to function. The entire 
signal path, from the Low Level Transmitter to 
the Receiver A/D encoders, is monitored. The 
High Level Transmitter is internally monitored 
exclusive of software. On failure of a Class A 
test, redundancy switching can occur or man is 
informed of the trouble. Man then can isolate 
the difficulty using Class B tests. These run 
interleaved with the Weapons Process and dis- 
place a small number of search channels of the 
radar template. In the event of a real or simu- 
lated engagement, the Class B tests are auto- 
matically terminated by software. 


The Class B tests provide fault location in 
the DCG." In most cases, they can isolate fail- 
ures to within three logic chassis. The Class B 
tests also provide periodic testing of all antenna 
elements. The remaining Class B tests permit 
performance evaluation of the receiver and over- 
all system. Sufficient flexibility is available to 
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permit operator selection of test conditions 
where appropriate. 


To prevent interruption of normal system oper- 
ation, the flexibility of Class B tests has to be 
limited. The Class C tests allow complete flex- 
ibility under test conditions and perform function 
tests that can only be accomplished with the 
entire MSR out of service. Normal MSR opera- 
tion can be rapidly reestablished from a Class 
C test condition, however. 


COMPARISON. OF PERFORMANCE 
OBJECTIVES AND RESULTS 

The performance of both the prototype MSR 
installed at Meck‘ and the tactical MSR installed 
in North Dakota, came very close to that speci- 
fied in the work statement?" prepared at the 
beginning of the development period. (See the 
Classified Supplement.) The development of 
each critical item — the antenna, transmitting 
klystron, low sidelobe chirp lines, andthe like — 
produced components with performance that 
equaled or exceeded the specification. The 
antenna, since this was one of the first phased- 
array systems, was a distinct challenge. The 
thoroughness in testing the prototype antenna 
design ensured achieving the required MSR per- 
formance and provided sufficient detailed infor- 
mation to compare the theoretical performance 
of-a phased array with the realized performance 
of an as-built array. This type of data can be 
utilized by designers of future arrays to evaluate 
the need for expensive antenna pattern measure- 
ments," 


The operation of the prototype system at Meck 
since mid-1968 has provided a wealth of infor- 
mation concerning the reliability of the radar. 
Accurate records on component failures have 
been kept since that time. Following the typical 
and expected high initial failure rates, the rate 
of failures in the entire complex quickly reached 
a level of less than one per day except for the 
high-usage drive amplifier and phase shifter 
diodes.“® These items are replaced periodically 


after a sufficient number of failures have occur- 
red to warrant change. The integrated diagnostic 
system has simplified locating and repairing 
each malfunction to a degree comparable with 
much smaller and simpler radars. 


The system has demonstrated the ability to run 
continuously for long periods of time and shows 
no abnormal wearout in any section of the appa~ 
ratus. The failure rate of the solid state com- 
ponents, such as transistors and high-power 
phase shifter diodes, is equal to or better than 
the design objectives. 


The original design did not contemplate an 
Electromagnetic Pulse (EMP) requirement which 
subsequently evolved. All elements of the MSR 
were then designed to meet this requirement and, 
in many instances, were tested specifically to 
demonstrate this.*° The results of the antenna 
hardening, particularly in the beryllia antenna 
element window, were most encouraging. See 
Chapter 6 for more information on hardening. 


The tactical system in North Dakota afforded 
an opportunity to observe the installation of this 
massive amount of electronic equipment. The 
ease with which the apparatus was installed, 
wired, and tested confirmed an adequate tactical 
design. Of particular interest was the simplicity 
of installing the space-feed antenna systems com- 
pared to the usual complex and time consuming 
corporate transmission system network. 


The beneficial capabilities of a phased-array 
antenna beam have been demonstrated during the 
prototype firings at Meck Island. The MSR pro- 
vides data on a very large number of reentry 
objects over a large area, and the comparison 
to previous "dish" antenna radar systems is 
quite dramatic in this regard. 


MAJOR CHALLENGES AND INNOVATIONS 


One of the major challenges to the MSR system 
was the development of a space-feed antenna hav- 
ing sufficient beam agility, low loss at S-band, 
accurate tracking capability, and ease of installa- 
tion and maintenance. The resulting design has 


met all of these objectives and has performed well 
in the very severe environmental requirements at 


Meck Island and North Dakota. 


The very low far-out sidelobes were achieved 
without resorting to special fabrication techniques 
requiring high precision. The long life of the 
high-power phase shifter diodes was achieved 
after a lengthy development period. This was the 
first application for diodes in this power range. 
The performance of the transmit feedhorn win- 
dow was achieved after a long period of design 
and testing. Its performance has been proven 
by both the Meck and North Dakota operations. 
The low failure rate of the antenna components 
and the very rapid antenna element checking 
system reduces the maintenance task on the 
phased-array antenna to a once-a-month or less 
often operation. The development of an antenna 
service vehicle simplifies even this maintenance 
task. The performance of the beryllia antenna 
element window both electrically and from the 
EMP standpoint was a significant achievement 
resulting from extensive development and testing. 


The development of the high-power klystron 
transmitting tube probably represented as severe 
a challenge as any item in the entire radar. The 
very high average power output in S-band, as 
well as the wide frequency bandwidth, were ob- 
jectives never before achieved. In fact, the 
S-band klystrons available at the beginning of 
the development period provided roughly an 
order of magnitude less average power output 
than the subsequent MSR klystron. This develop- 
ment has produced RF power at the S-band fre- 
quency at a lower cost per watt of power than 
that produced at any other frequency. In addi- 
tion, the requirement of only two tubes produces 
a transmitter design of high reliability and low 
maintenance cost. 


Utilizing the high power from the klystrons 
created problems with the power-handling capa- 
bility of the S-band waveguide transmission sys- 
tem connecting the transmitter to the antenna. 
These problems required considerable develop- 
ment effort since average power levels of this 
magnitude had never before been attempted with 
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S-band waveguide and waveguide components. 
Final solutions were readily achieved and several 
years of operation, including operation of the in- 
stallation in North Dakota, has verified their 
effectiveness. 


The klystron collector cooling channel design 
was marginally able to cause cavitation-related 
erosion. This did not appear until the Grand 
Forks equipment was inadvertently operated at 
low static pressure.*> When the roughness was 
completely removed by a sulfuric acid flush and 
high static pressure was maintained, no roughen- 
ing occurred due to erosion. The high pressure 
apparently prevented the nitrogen entrained in 
the water from forming bubbles at low pressure 
points in the collector. Such bubbles led to the 
rough erosion. 


Installation and test of the radar digital con- 
trol equipment at TSCS permitted early detection 
and correction of design deficiencies. Tests 
with system software of increasing complexity 
turned up logic and timing problems of increasing 
subtlety. As the DCG is a wired logic computer, 
the solution of these problems required logic 
changes. It should be noted that logic design 
changes could be expeditiously implemented due 
to the highly automated design process used for 
SAFEGUARD digital equipment. Solving problems 
at TSCS resulted in required performance at 
Grand Forks, showing that reproducibility was 


easily achieved. However, as TSCS was a partial, 
nonredundant DCG with only a skeleton Beam 
Steering Computer, residual problems did occur 
during Grand Forks testing particularly where 
DCG redundancy was involved. These problems 
were corrected on site. 


Of particular importance was achieving the 
availability and reliability objectives for the 
radar system. With the success of the entire 
engagement dependent entirely on a single radar 
complex, attaining these requirements was man- 
datory. Several years of operation in a firing 
program at Meck Island has established that 
the MSR with its redundancy can meet the very 
stringent availability and reliability requirements. 
Redundancy switching of receivers, transmitters, 
and radar control equipment has been demon~ 
strated during engagements, including those with 
an interceptor missile in flight. 


The requirement for very low-range sidelobes 
in the chirp system used in the MSR was impor- 
tant. The very small target size of the incoming 
reentry vehicle in relation to its surrounding 
objects mandated a solution to this problem. 

The delay lines resulting from the development 
program did meet these requirements and ex- 
hibited such excellent stability that performance 
could be obtained on a day-to-day basis over 

a long period. 





Meet Hts os ' , 












baneek tesa Kacteretets na bee teed betas es ben becca ieee vas, Geeued bshucegeld 




















afer t 2 ans aR 44 : 






ef 
7 























Introduced in the Spring of 1965 as an adjuncc 
to a full-scale NIKE-X deployment, the Perim- 
eter Acquisition Radar (PAR) was to be an un- 
hardened, early warning VHF radar. Later in 
1965, a limited NIKE-X deployment was pro- 
posed with the VHF PAR as one of its major 
components. This NIKE-X proposal triggered 
a 12-month "definition and contractor selection". 
phase for PAR. By October 1966, Bell Labora- 
tories had established the PAR requirements and 
requested quotes from several major contractors. 
The proposals were received and evaluated by 
December 1966, and a contract was awarded for 
an "initial definition phase'’* to General Electric 
Company (GE), Syracuse, New York. During this 
initial definition phase, detailed requirements! 
were generated, a configuration was selected, 
and development of critical components was 
started. 


_ Anew deployment concept evolving from the 
NIKE-X program was introduced during January 
1967 and designated I-67. The I-67 System de- 
ployment, later to become the SENTINEL Sys- 
tem, consisted of SPRINT and SPARTAN mis- 
siles, Missile Site Radars (MSRs), and PARs. 


*A two-phase effort was undertaken in which 
Phase I was Definition and Phase II Development, 


Chapter 8. 
PERIMETER ACQUISITION RADAR 


In this concept, PAR was redefined from an early 
warning radar to one that could provide initial 
target detection, discrimination, and tracking 
for long-range SPARTAN intercepts. The addi- 
tional requirements created by the new "area de- 
fense concept" redefined the PAR as a VHF radar 
in the forward portion of the defended area and 
hardened so that its integrity would be maintained 
during an attack. 


In April 1967, after General Electric com- 
pleted the Phase I VHF effort,’ the Phase 1 
portion of PAR was temporarily delayed until a 
major problem could be solved. With the redirec- 
tion of its role, PAR was now subject to nuclear 
blackout from the bursts of SPRINTand SPARTAN 
missiles. Results ofa study on nuclear blackout, 
conducted the previous summer by the Institute 
for Defense Analysis, concluded that since the 
blackout problem was significantly less severe at 
UHF than at VHF, the PAR frequency band should 
be changed to UHF. Largely as a result of this 
study, a joint decision between Bell Laboratories, 
the Army, and the Department of Defense shifted 
the PAR operating frequencies to the UHF band. 
By May 1967, one month after the UHF decision, 
new detailed requirements for the PAR were es- 
tablished; many major configuration decisions 
regarding types of transmitters, number of faces, 


antenna size and type, and waveform types were 
determined; and the development of critical com- 
ponents was begun. 


In September 1967, the decision was made to 
deploy the system embodied in the I-67 
(SENTINEL) proposal. Approval was given to 
General Electric to begin Phase I — the detailed 
design and manufacture of the PAR equipment.?-! 
After defining the complete radar system con- 
figuration, the detailed design of the PAR build- 
ing and power plant began in June 1968. 


The planned PAR configuration?" in many 
ways was similar to that of a Multifunction Array 
Radar (MAR-I — an L-band radar that has been 
constructed and thoroughly tested at White Sands 
Missile Range between 1964 and 1966). MAR-I 
had separate transmit and receive arrays anda 
one-to-one ratio of receivers and transmitters 
to antenna elements, but each array was corpor- 
ate-fed, its transmitter used multiple Traveling 
Wave Tubes (TWTs), and its receiver used para- 
metric amplifiers similar to those originally 
planned for PAR. Since the experience gained 
from MAR-I was directly applicable to PAR 
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and components in the UHF band were thought 
to be available, much of the PAR design was 
considered to be "off the shelf.'' Development 
of a complete prototype system, therefore, 
was deemed unnecessary, * and it was decided 
to construct the first PAR [the Research and 
Development (R&D) model] at a site where it 
would become part of the operational system 
after the R&D phase was completed. In the 
SENTINEL Area Defense Plan, this site was to 
be located in the Boston, Massachusetts, area. 


In March 1969, the SENTINEL Area Defense 
System was reoriented to the SAFEGUARD Sys- 
tem Minuteman Defense Concept and the first two 
SAFEGUARD sites were selected in North Dakota 
and Montana, with North Dakota chosen as the 
R&D site for the PAR. (See Figure 8-1.) In 
lieu of an R&D radar for design confirmation, 2 
Limited Engineering Development Model (LEDM) 


*As discussed in Part IT — Management and 
Overall Approach — althoughthis decision may 
have been satisfactory from a hardware stand- 
point, it led to severe system design penalties 
in the final ABM effort. 





Figure 8-1. PAR Site — North Dakota 














was constructed by General Electric. This pro- 
vided a test bed for prototype models of com- 
ponents used singly in the system (e.g., the 
signal generator and exciter for the transmitter 
and the signal and data processor of the receiving 
chain) and for a significant quantity of each com- 
ponent used in large numbers within the final 
system (e.g., antenna elements, phase shifters 
combiners, and transmitter TWTs). 


During 1969 and 1970, a major part of the 
PAR development and test activity involved use 
of the LEDM at Syracuse, New York. This pro- 
gram continued until May 1971 and verified the 
design and performance of the high-usage items. 
It established methods for their test and main- 
tenance (including limited-life testing) and veri- 
fied their interface with the rest of the system. 


The PAR transmitter design (Figure 8-2) 
was approved in early 1970 and released for 





Figure 8-2. PAR Transmitter 


manufacture. Qualification testing of the TWTs 
by Raytheon was completed, the tube design was 
frozen, and production was started for the LEDM 
and the first PAR. Several hundred antenna ele- 
ments and over 120 phase-shifter models were 
manufactured and tested in the LEDM. The low- 
noise transistor amplifier was developed, tested 
in the LEDM, and authorized for use in place of 
the parametric amplifier. 


A construction contract was awarded for 
PAR-1 in North Dakota and PAR-2 in Montana 
in 1970 and actual construction!*3 began at these 
sites in April 1970. During the year, Critical 
Design Reviews (CDRs) were held by the Army 
resulting in the release of the PAR designs. 


Toward the end of 1971, the Army Corps of 
Engineers installed the heavy duty equipment at 
the PAR-1 site. Work continued on both sites 
until August 1972 when, as a result of the 
Strategic Arms Limitation Treaty (SALT) Agree- 
ments, a decision was made to terminate any 
further work on PAR-2 in Montana. Figure 8-3 
summarizes the PAR design history. 


During the period from August 21, 1972 
[Building Occupancy Date (BOD)] to September 
27, 1974 [Equipment Readiness Date (ERD)], 
an intensive test program to verify system per- 
formance was executed." This is detailed in 
Figure 8-4. The majority of testing was im- 
plemented with software (see Chapter 4, 
SAFEGUARD System) developed at the Tactical 
Software Control Site (TSCS) at Madison, New 
Jersey. The success of the test and evaluation 
activity was largely due to the timely delivery 
of the many high-quality test software packages 
to the North Dakota PAR site. The software 
schedule is shown on Figure 8-5. 


The initial alignment of the radar was com- 
pleted by August 1973. During this month, the 
first satellite track and the first radio-star track 
were successfully accomplished. 


Work continued past ERD to prove-in the PAR 
Weapons Process (PW) software for threat con- 
ditions exceeding those required at ERD. This 
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included system testing of the PAR netted with the 
MSR and the Ballistic Missile Defense Center 
(BMDC). Additional work was scheduled beyond 
the Initial Operational Capability (IOC) date in 
April 1975 and would continue, during a Con- 
tractor Technical Maintenance program imple- 
mented by Western Electric Company, to final 
operational capability. 


SUBSYSTEM DESCRIPTION 


The PAR is a phased-array radar, operating 
at UHF, which performs long-range surveillance 
to detect and track enemy ballistic missiles for 
intercept by the SAFEGUARD missiles. As an 


auxiliary function, it provides tracking data to 
North American Air Defense Command (NORAD) 
on selected satellites. The PAR is designed to 
perform its mission in an environment that may 
consist of false targets (aircraft, satellites, 
aurora, and meteors) and nuclear weapons effects. 
To withstand nuclear effects, the radar equipment 
is designed to meet specified environmental cri- 
teria. The radar is housed in a 128-foot high 
hardened reinforced concrete building that pro- 
vides protection against nuclear thermal radia- 
tion and Electromagnetic Pulse (EMP) effects. 
The front of the building is inclined at a 25- 
degree angle from vertical, faces almost directly 
north, and supports a phased-array of 6888 
antenna elements'® (Figure 8-6). The building 











Figure 8-7. PAR Building, Cutaway View 


required 17 million pounds of steel reinforcing 
bars and more than 58,000 cubic yards of con- 
crete, The base of the structure is 200 feet 
square and 11 feet thick. The PAR face contain- 
ing the radar elements is 7 feet thick. Adjacent 
to the PAR is an underground power plant con- 
nected by a 130-foot tunnel. A cutaway view of 
the radar is shown in Figure 8-7. 


The PAR searches the volume of space within 
a large solid angle in front of the array face at 
regular intervals. It can detect small targets 
in a typical ballistic missile complex at large 
distances with a high probability of detection. 
Both the radar operating frequency and the an- 
tenna beam-pointing direction can be varied 
rapidly. T6 optimize performance, separate 
antenna illumination functions are used in the 
transmit and receive modes. In the transmit 
mode, an asymmetrical phase taper is applied at 
low pointing angles to reduce the peak sidelobe 
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power radiated toward the ground and enhance the 
system's electromagnetic compatibility.” In the 
receive mode, an amplitude taper is used to re- 
duce near-in sidelobes and minimize the effects 
of interference and jamming. 


A block diagram of the radar is shown in 
Figure 8-8, The PAR transmitter consists of 
16 groups of 8 (a total of 128) high-power TWTs, 
which amplify a chirped waveform generated by a 
common exciter. The combined total peak ra- 
diated power is in the multimegawatt range, and 
the transmitter operates at an unusually high duty 
cycle. The energy from each TWT is divided to 
feed two 24-element subarrays or a total of 48 
elements. 


Target returns are amplified by 256 low-noise 
transistor amplifiers, which are an integral part 
of the phase-steered, corporate-fed array. One 
transistor amplifier is used for each receive 
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Figure 8-8. PAR, Block Diagram 


subarray of 24 antenna elements. The receive 
signals are combined into appropriately formed 
search and track beams and then are processed 
by an RF signal processor. 


The Digital Data Group (DDG) interfaces with 
the PAR Data Processor and provides timing 
signals and instructions for controlling the radar. 
Phase steering commands are generated in the 
DDG by the Beam Steering Computer (BSC). The 
digital equipment consists of two identical chan- 
nels that operate simultaneously. Comparisons 
are made between the channels at numerous 
points to ensure errorless operation. This fea- 
ture permits real-time fault detection and facili- 
tates the isolation of a malfunctioning channel. 


Radar performance is monitored by cyclic 
tests performed automatically every 50 milli- 
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seconds. Test signals are injected into a bi- 
directional element test network, which is used 
to distribute test signals to or from each antenna 
element for monitoring the receiver or for col- 
lecting samples of transmitter energy. Class A 
tests employ the element test network to monitor 
critical battle performance functions such as 
receiver sensitivity, transmitter power, and 
angle error. These tests are automatically in- 
terleaved with the tactical programs. Class B 
tests, performed on command by light-pen action 
at the Radar Maintenance Console, are used to 
monitor and display characteristics such as the 
transmit/receive antenna beam shape. Changes 
in the antenna beamforming alignment can be 
performed using Class B measurement data 
gathered through the element test network. 


Equipment status is continuously displayed at the 
Radar Maintenance Console, where all perfor- 
mance and maintenance monitoring functions can 
be initiated by the console operator. Simulated 
test targets originated by the Data Processor are 
formed in the Radar Return Generator and in- 
jected into the signal processor's IF input. 


COMPARISON OF PERFORMANCE 
OBJECTIVES AND RESULTS 

The PAR subsystem performance require-~ 
ments!® were met or exceeded in almost every 
instance. An extensive test program was carried 
out to assure design compliance with special en- 
vironmental requirements." This program ana- 
lytically assessed all the system components and 
performed experimental tests on a selected set 
of components representing each major design 
item. With the exception of the TWTs and certain 
retaining and fastening apparatus for which the 
vulnerability was assessed at 75 percent of the 
design level, all mission-critical equipment 
withstood the nuclear shock and vibration spec- 
‘trum requirements.! 


The PAR electrical performance parameters 
met or exceeded their required values in every 
instance. (See the Classified Supplement.) Due 
to higher transmitter power, better than ex- 
pected receiver sensitivity, and slightly higher 
antenna gain, the overall system performance 
was about 4 dB greater than specified. 


Power density measurements, made on the 
ground in front of the PAR while the radar was 
operating in the tactical search mode, showed 
that the average power density was well below the 
10-milliwatts/square centimeter hazardous levels 
at all ranges. Other tests verified the PAR's 
electromagnetic compatibility with USAF air- 
craft and Canadian communication equipment. 


Using an airplane-borne signal source, a 
somewhat limited antenna pattern measurement 
program (main beam and sidelobes) demonstrated 
that the internal method of injecting a signal at 
the element test coupler yielded results compar- 
able to external measurements of an array-normal 


beam. The results showed agreement between 
the theoretical, internal, and external measure- 
ments within the stability* of the element path 
phase and amplitude values. A view of the PAR 
with the antenna measuring radar on top of the 
building is shown in Figure 8-9. 


MAJOR CHALLENGES AND INNOVATIONS 
VHF versus UHF 


In 1967 when the PAR was changed from an 
early warning alert system to one that could 
provide tracking for the SPARTAN intercept 
role for area defense, studies were under- 
taken to redefine its capabilities in light of the 
new requirements.”-3 As mentioned previously, 
the Institute for Defense Analysis study of nu- 
clear blackout effects as a function of frequency 
resulted in. changing the transmitted frequency 
from VHF to UHF. In addition to the reduced 
severity of nuclear effects at UHF, this frequen- 
cy band was expected to ameliorate disturbances 
caused by the intense aurora of the northern 
latitudest and would be less likely to cause radio 
frequency interference problems. However, 
since there would be less target enhancement 
due to length resonance effects and some loss in 
equivalent target cross section at the higher 
frequency, an increase in the power aperture 
product was required. The UHF implementation 
required an increase in transmitter power by a 
factor of four. This increased cost was offset 
by the use of novel, block-combining techniques 
in the receiver and adaptation to a single, common 
transmit/receive array in place of the previous 
dual aperture design. The common aperture 
required less space, fewer elements, and only 
a single set of beam steering hardware and ele- 
ment phase shifters. Although a space feed was 
planned for the MSR, the extremely large ane- 
choic chamber required by the PAR at UHF was 


x 


*This stability includes minor drifts on a short- 


term (days) basis. 


1Bell Laboratories conducted a study at Prince 
Albert Radar Laboratory in Canada to in- 
vestigate auroral effects at UHF.36 
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Figure 8-9. PAR, Showing Antenna Measuring Radar on Top of Structure 


considered impractical and wasteful of space in 
a hardened structure. Hence, a corporate feed, 
similar to that of the previous MAR, was used 
for the PAR, 


Transmitter 


After considerable study??"5 and review, TWTs 
(Figure 8-10) were finally chosen for the trans- 
mitter power amplifier. Several factors were 
involved in this selection. 


e The tube was expected to have high relia- 
bility and long life (30,000 hours) since it 
was a scaled model of the proven L-band 
design developed jointly by Bell Labora- 
ae and Raytheon for use in the NIKE-X 

R. 


e The power output per tube made it a con- 
venient unit to provide the required total 
summed power of 128 tubes. 


e The choice enhanced reliability because 
of the inherent redundancy of multiple 
transmitter power sources. 


Previously, tetrodes had been a leading contender 
in the General Electric design, but their reliabil- 
ity could not approach that of the TWT and power 
output would have had to be sacrificed for band- 
width. Solid state power amplifiers were also 
investigated, but their cost was not competitive 
with the TWT and there was little background to 
assure the development of such a transmitter 
within the time schedule. 


The choice of a transmitted pulse waveform 
was related to the transmitter decision and in- 
volved some interesting tradeoffs. In working 
with solid state transmitters, consideration must 
be given to using a long, 6-millisecond, CW pulse 
to minimize peak power. When the decision was 
made to use the TWT, the required pulse energy 
could be obtained with higher peak power and 
shorter pulses. The desired range resolution was 
obtained using a chirped pulse with a compression 
ratio of 100 to 1. 





Figure 8-10. PAR Traveling Wave Tubes 


The decision to use a chirped pulse provided a 
second-order benefit as demonstrated by the Prince 
Albert Radar studies.3* It was found that in an 
auroral environment, the clutter returned was 
approximately proportional to the size of the range 


resolution cell. Therefore, a chirped pulse 
would return less clutter than an equal energy 
CW pulse, roughly in proportion to the chirp 
compression ratio. In addition, with a chirped 
system, the signal processor was much reduced 
in complexity since a single dechirp filter re- 
placed the banks of filters, each matching a 
different doppler frequency, which would be re- 
quired for a pulsed CW, search signal processor. 
Dispersive delay lines needed for the chirped 
pulse were available from the ZEUS Acquisition 
Radar and were modified for use in the PAR. 


Antenna Element 


The high powered, hardened elements (Fig- 
ure 8-11) were one of the most vulnerable entities 
in the PAR design. General Electric was re- 
quired to design them to withstand the combined 
direct effects of the blast and elevated tempera- 
tures of a nuclear explosion. The final design 
consisted of crossed-dipoles fabricated from 
beryllium copper, and inclined 45 degrees to- 
ward the array face. Phase correcting stubs 
were placed midway between each element to 
decrease the polarization ellipticity at wide scan 
angles. A Hardness Verification Test Program” 
(see Chapter 6) proved the capability of these 
elements to withstand nuclear attack with mini- 
mal degradation of electrical and mechanical 
properties. Environmental tests verified their 
ability to perform despite severe rain, ice, or 
snow accumulation. 


- Phase Shifter 


Another notable development was the phase 
shifters (Figure 8-12), which are located di- 
rectly behind the array and provide both transmit 
and receive beam steering. 


Several designs were considered, including 
ferrite phase shifters, a lumped-constant micro- 
strip phase shifter similar to the MSR unit, and 
a distributed constant*diode-switched transmis~ 
sion line configuration. While the lumped-con- 
stant microstrip device was smaller and tended 








Figure 8-11. PAR Antenna Element 
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8-12, PAR Phase Shifter 
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to simplify space and maintenance requirements, 
its advantages were not considered significant 
when the PAR deployment was reduced to one site, 
The final design used high power PIN diodes 
for switching in an air-dielectric strip trans- 
mission line. 

Extensive tow-power and high-power tests 
were performed on these diodes to evaluate their 
characteristics and confirm their reliability. 


Receiver RF Amplifier 


Parametric amplifiers were initially con- 
sidered for the PAR RF receive amplifiers 
because of their low-noise figure and the ex- 
perience gained from their use in previous MAR 
designs. The improvement in low-noise trans- 
istors over the years, particularly some de- 
veloped by Texas Instruments* for this frequency 


*Before transistors of reasonable yield, high per- 
formance, and reliability were finally delivered 
by Texas Instruments, a great deal of consulta- 

. tion, assistance, and technical direction was 
required from several Bell Laboratories tech- 
nical areas. 


band, indicated that a transistor RF amplifier had 
definite advantages. The transistor amplifier 
was smaller, less expensive, easier to adjust 
and maintain, and had an improved noise figure 
and significantly lower power requirements than 
the parametric amplifier. 


Maintenance and Redundancy 


The maintenance philosophy was based on a 
balance of component availability /reliability 
versus the cost of providing redundant units. 
The result of this balance was to provide redun- 
dant exciters, waveform generators, angle error 
detectors, analog-to-digital converters, radar 
control and conditioner units, beam steering 
calculators, and input-output controllers. The 
redundant Digital Data Group was designed to 
operate synchronously with the on-line unit. 
Error detection was designed to compare signals 
and, under software control, to automatically 
switch to the "good" unit. Redundancy was also 
built into the Data Processing System by pro- 
viding one spare unit in each of the Processor, 
Program Store, and Variable Store Units of 
the Central Logic and Control. 
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The objective of the SPRINT Development 
Program was to develop a missile subsystem 
capable of terminal defense intercepts at any 
azimuth, at relatively close ranges, and at alti~- 
tudes at the extremes of the sensible atmosphere. 
The smallest practical vehicle capable of fast 
delivery of a specified nuclear payload was re- 
quired? 


The missile was to be launched from an under- 
ground emplacement. A short reaction time was 
required to allow interception of an incoming Re- 
entry Vehicle (RV) after it had penetrated the at- 
mosphere and could be separated from debris or 
decoys by the effects of aerodynamic drag. The 
short reaction time demanded quick launch prep- 
aration and high missile-acceleration rates, 
High rates of control response and missile ma- 
neuverability also were required to allow time 
for ground radar to pinpoint the prime target and 
to effectively guide the missile to the intercept 
point. 


The development effort was subcontracted to 
the Martin Marietta Corporation, Orlando Divi- 
sion, in May 1963. The task was to design a 
missile subsystem which could be manufactured 
and deployed by 1970.2 The organization for the 
R&D effort that subsequently evolved is shown in 
Figure 9-1. 
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Chapter 9, 
SPRINT MISSILE SUBSYSTEM 


The early deployment date for a missile with 
advanced performance characteristics dictated 
an all-out development program to prove feasi- 
bility, reliability, and producibility quickly. Six 
months were allotted to a program definition 
phase prior to the formal development start. 
During the definition phase, it was decided that a 
single complete missile design would be readied 
for initial flight testing. This "all-up" approach 
required very careful design and extensive com- 
ponent testing, but had the advantage of offering 
complete subsystem test data on every missile 
flight. The first flight test was scheduled 25 
months after development go-ahead, and this 
milepost was successfully met on November 17, 
1965. However, while the program was underway, 
pressure for rapid development lessened, system 
requirements were changed, and the program du-~ 
ration was lengthened to support limited deploy- 
ment in 1974-75."5 


Flight testing was conducted at White Sands 
Missile Range (WSMR) between 1965 and 1970, 
and was then shifted to the Kwajalein Missile 
Range (KMR) for integration with other parts of 
SAFEGUARD in system tests and live target in- 
tercepts.°? Deployment of SPRINT missiles at 
North Dakota began in June 1974. 
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MAJOR CHALLENGES AND INNOVATIONS 


The implementation plan to develop and deploy 
an interceptor missile to meet the terminal de- 
fense concept required fabrication of a vehicle 
that would surpass the performance of previous _ 
missiles in many respects. Problems requiring 
solution included: 


e A highburning rate propellant which could 
maintain high g-loads had to be developed. 
The required burning rate represented an 
order of magnitude increase in solid pro- 
pellant burning rates over that in use on 
such missiles as Pershing, Polaris, and 
Minuteman. 


e The ablative heat shield had to survive a 

’ Jlow-trajectory, high-velocity environment 
that generated extremely high boundary- 
layer temperatures without allowing the 
underlying missile structure to be exposed 
to destructive temperature, Also, ablative 
materials had to be free of contaminants 
which would attenuate radar communica- 
tions .8 


e Electromechanical and electronic compon- 
ents had to be designed to function at ex- 
tremely high levels of shock, acceleration, 
and vibration. These levels exceeded the 
capability of the then-available technology .9” 


e Communications had to be maintained 
through the missile plume and ion sheath, 
At the beginning of the program, it was 
impossible to define the chemistry of the 
boundary layer in which this ion sheath 
was generated. 


e The control system had to maintain stabil- 
ity for all flight conditions, including flight 
close to nuclear blasts. 


e Thrust vector control requirements dictated 
the need to design a valve with a flow rate 
an order of magnitude higher than that in 
Minuteman. 


e The missile structure and all its subsys- 
tems, including electrical components, had 
to withstand severe nuclear effects. The 
extensive program that achieved and 
assessed nuclear hardness has been 
thoroughly documented! For more in- 
formation on this program, see Chapter 6. 


DESCRIPTION 
Missile? 


The SPRINT missile!?is deployed in an environ- 
mentally controlled underground vertical launch 
station in a dormant state."45 A cutaway of the 
launch station with its missile is depicted in Fig- 
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ure 9-2. Periodic tests of the missile subsys- 
tem are conducted to assure availability of the 
missile for instant launching. The missile is 
prepared for launch in a very short interval. * 





*Specific missile performance parameters (.¢., 
preparation interval, motor burn rates and 
times, missile weights, velocities, and control 
capabilities) can be found in the Phase II De- 
velopment Plan SPRINT Subsystem. 





Figure 9-2. SPRINT Missile and Launch Station 


When launch orders are given, the missile bat- 
tery is activated, wiring circuits are checked, 
missile gas generators are ignited, control sys- 
tem hydraulic pressure in each stage is checked, 
first-stage thrust vector control valves are 
moved, and the second-stage aerodynamic con- 
trol vanes are wiggled. Orders for the proper ini- 
tial turn toward the intercept point are preset into 
the missile guidance set. The launch station 
cover is then explosively opened, the ground 
power umbilical cables are disconnected, the 
launch-eject gas generator is fired, and the mis- 
sile is expelled from its launch station by a pis- 
ton. The first stage ignites as the missile clears 
the launch station." 


The short first-stage burning provides a very 
high acceleration resulting in high velocity at 
burn out. Division of energy between the two 
stages is not optimized for maximum missile 
velocity, but is biased in favor of making the 
second stage smaller for better maneuver control. 


First-stage separation is initiated by skin- 
cutting ordnance activated by ground command. 
' After drag forces push the burned-out first stage 
away, thesecond stageisignited by a preset signal 
or by ground command.” Second-stage ignition 
may be delayed either to extend interceptor range 
or to assure a higher dynamic pressure and high- 
er maneuverability for end-game guidance to in- 
tercept. Intercepts can be executed beginning 
midway in the second-stage burning provided a 
minimum altitude requirement has been satisfied. 


The flight time and maximum range capabili- 
ties of the initial missile design were later ex— 
tended by adding a lubrication system to the sec- 
ond stage hydraulic motor pump and by enlarging 
the second-stage gas generator. 


The SPRINT missile is conical with a length 
of 27 feet and a base diameter of 4.4 feet. At 
launch, it weighs about 7600 pounds. The main 
sections aré illustrated in Figure 9-3. The mono- 
coque airframe uses fiberglass filament-wound 
motor cases as a primary structure. The remain- 
ing load-carrying structure is aluminum. 
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The thermal protective system of the second 
stage is designed to maintain the structural in- 
tegrity of the aluminum alloy shell and the fiber- 
glass motor case. The ablative nose cone con- 
sists of a hemispherically tipped, one-half-inch 
diameter nose cap flaring into a 6-degree half- 
angle conical section. The nose cap is formed 
with a center rod of quartz phenolic over which is 
wrapped phenolic-impregnated silica tape. The 
ablative shield covering the rest of the second 
stage is fabricated from silica cloth impregnated 
with phenolic resin mixed with rubber to allow 
additional elasticity. An exception is the material 
covering the leading edges of the air vanes. Be- 
cause of the high heating rates imposed on these 
components, the leading edges are protected by 
molded edge-oriented quartz phenolic tape. 


Since the first stage has a very short flight 
time and does not attain velocities nearly as high 
as in second-stage flight, sufficient protection of 
its structure is achieved by a coating of Epon 946. 


Both before launch and during flight, missile 
commands are transmitted from the Missile Site 
Radar (MSR) to the Missile Guidance Set (MGS), 


’ where the commands are decoded and applied to 


the autopilot." After launch orders, the auto- 
pilot sends signals to actuate the thrust vector 
control valve pintles which determine missile 
azimuth angle and pitchover angle after the 
missile leaves the silo.2!| Throughout flight, sig- 
nals are sent to the second-stage air vanes to 
provide missile stability and maneuverability to 
the intercept point. The autopilot contains iner- 
tial sensors which maintain a stable roll refer- 
ence and generate roll rate, pitch rate, yaw rate, 
pitch lateral acceleration, and yaw lateral accel- 
eration signals for control system feedback. It 
also contains the de and ac electrical power sup- 
plies for the missile. 


The first-stage thrust vector control uses 
Freon* as a vectoring fluid to provide pitch and 


*Registered trademark of E. I. DuPont de 
Nemours. 
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yaw forces. Freon flow is metered through each 
of the four three-barrelled injection valves which 
are positioned by transfer valves using hydraulic 
oil as the working fluid. A solid-fuel gas gener- 
rator pressurizes the Freon and hydraulic oil ac- 
cumulators. 


Second-stage air vanes are controlled by 
servo-actuators supplied with hydraulic oil from 
a closed-loop system containing a hot gas-driven 
motor pump. An accumulator provides the extra 
hydraulic power capacity to meet system trans- 
ient flow requirements. The hot gas motor 
pump consists of a positive displacement gas 
motor integrally connected to a constant volume 
hydraulic pump. The motor pump produces 26 
horsepower and weighs only 10.2 pounds. Over- 
speed of the pump is prevented by incorporation 
of a flow limiter, and lubrication is provided by 
a secondary gas-operated accumulator. 


Both first- and second-stage motors are coni- 
cally shaped, with cases made from filament- 
wound fiberglass with an epoxy binder." Propel- 
lant for both motors is composite modified double 
base. Theignitiontrain consists of a High-Energy 
Firing Unit (HEFU) capacitive discharge to an ex- 
ploding bridgewire initiator firing into a basket of 
boron/potassium nitrate pellets which ignite the 
main propellant. 


The missile electrical system consists of the 
battery system, inverter, interconnecting box, 
initiation system, umbilical and interstage con- 
nectors, and wiring harnesses. The Launch 
Preparation Equipment (LPE) provides power to 
verify missile operations during the periodic sub- 
system tests. This ground power enters the mis- 
sile through umbilical connectors located just 
under the nose section. During the launch se- 
quence, the umbilicals are automatically discon- 
nected, the missile battery is activated, and, as 
the missile is launched, the nose cap slides down 
over the connectors to provide a continuous 
unbroken heat shield over the missile. 


The SPRINT missile (and SPARTAN) is guided 
by a radio command guidance system which 


consists of ground-based radars, a ground-based 
computer, and the Missile-Borne Guidance Equip- 
ment (MBGE).”:* The functions of the MBGE 
are: 
e To receive and decode missile command 
steering orders 


e To receive and decode discrete commands 
for payload activation, destruct signals, or 
other purposes 


e To receive and decode an autopilot gain con- 
trol signal which is a function of computed 
dynamic pressure © 


e To transpond a beacon signal for ground 
station radar tracking purposes. 
The MBGE consists of a Missile Guidance Set 
(MGS), an RF cable assembly, and three an- 
tennas.* The MGS, shown in Figure 9-4, con- 
sists of the: 


/ 


Superheterodyne receiver 
Beacon transmitter 
Amplifier-decoder group 
Power supply 

Burst delay timer. 


Major MGBE design requirements included 
nuclear hardness, reliable operation in a severe 
acceleration and vibration environment, and min- 
imal weight and volume. 


The MGS contains a pulsed, three-channel, 
superheterodyne receiver that uses space diver- 
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sity reception.” Each of the three channels is 
connected to one of the three antennas located . 
120 degrees apart on the airframe. The three 
channels of S-band, pulse-coded RF signals are 
heterodyned in microwave stripline mixers with 
the output of a single crystal-controlled solid- 
state local oscillator to obtain a pulsed IF signal. 
Each of the three channels is converted to a 
separate and distinct IF signal; these are com- 
bined in a single, main IF amplifier and limiter 
unit. This procedure enables the MGS to perform 
a power comparison between antennas. The an- 
tenna receiving the strongest signal is selected 
for radiation of the MGS beacon reply. 


The rapid and deep signal-level fades expected 
from rocket plume and plasma sheath dictated use 
of an IF limiter arrangement. Another approach 
using an AGC system would have required a pro- 
hibitively long time interval to recover from sud- 
den signal-level changes. 


The MGS contains an S-band transmitter keyed 
by receipt of a valid message from the MSR. The 
transmitter consists of a solid-state moduiator, 

a pulse-forming network, and a planar triode. A 
solid-state modulator was chosen over hard- and 
soft-tube modulators after consideration of the 
weight volume, reliability, life, and vibration 
environment. 
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Figure 9-4, SPRINT Missile Guidance Set, Block Diagram 
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The decoder translates the coded command 
information transmitted by the guidance radar 
into signals compatible with the autopilot and 
warhead adaption kit. The input consists of the 
video output from the missile-borne receiver. 
The decoder outputs are in the form of amplitude 
or pulse-width modulated ac signals to the auto- 
pilot and ac signals to the warhead. The decoder 
employs transistorized digital techniques for 
message decoding, storage, and signal condi- 
tioning. A single code-type, high-reliability 
logic transistor is used throughout the decoder. 


The Data Processing System (DPS) on the 
ground continuously updates the time to intercept 
for each missile during an engagement. This 
changing time interval is sent to each missile via 
the MSR link. The message is decoded in the 
MGS. A burst delay timer within the decoder 
starts to time out on the command time interval. 
Should the missile be enveloped in nuclear- 
induced blackout, resulting in a loss of communi- 
cations with the MSR and DPS, the burst delay 
timer will send a burst command to the warhead 
at intercept. , 
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The development program for the missile- 
borne guidance equipment (including the MGS) 
used on SPRINT is covered in Chapter 10, 
SPARTAN Missile Subsystem.?5% 


Launch Station 


The launch station, shown in Figure 9-5, 
consists of a cylindrical reinforced steel shell, 
8 feet in diameter and 31 feet long. It houses 
a steel launch tube, the launch-eject mechanism, 
and the missile. The shell is closed at the bottom 
by 2 welded steel baseplate which rests on a con- 
crete base. A compartment welded to the side 
of the launch shell houses the launch preparation 
equipment” and the environmental control 
system, 


The missile is mounted on a launch-eject 
piston which is supported by 10 helical springs 
for nuclear and earthquake shock isolation. The 
springs are bolted to an intermediate baseplate 
and are electrically insulated from the piston. 
The launch-eject gas generator is located below 
the piston and is surrounded by a flame shield. 
During launch, upward motion of the launch-eject 
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- Figure 9-5. SPRINT Launch Station 


9-7 


piston is stopped within the launch cell by four 
crushable aluminum honeycomb arrestors. The 
missile is thus separated and protected from its 
launch~-eject piston. 


The umbilical retractor assemblies are 
mounted on the launch station wall, and are ac- 
tivated at launch to retract ground power and 
communication lines. The top of the launch sta- 
tion is closed by a fiberglass structure which is 
explosively cut into sections, allowing missile 

" flythrough during the launch sequence. The clos~- 
ure provides environmental protection for the mis- 
sile and equipment within the launch cell. 


The missile and launch system are protected 
from hostile environments by the launch cell 
structure, shielding, and shock isolation sys- 
tem,:28 In addition, the Environmental Control 
System (ECS) controls the temperature and hu- 
midity in the launch cell and Launch Preparation 
Equipment Compartment (LPEC). The launch cell 
is maintained at 80 degrees Fahrenheit +10 de- 
grees and the LPEC temperature requirement is 
40 degrees Fahrenheit through 125 degrees Fahr- 
’ enheit. The temperature of the launch cell is 
controlled by the cell closure flange heaters 
(calrod type) and heater-blower combinations 
within the launch cell. The LPEC temperature 
is maintained through a strip heater-blower com~ 
bination. The humidity is held below 50 percent 
by the use of desiccants. There are two desic- 
cant chambers per launch station. The con- 
trols for the ECS are located in the LPEC within 
the LPE rack. 


The LPE prepares, tests, and launches the 
missile upon command from the DPS. The Launch 
Sequencer (LSEQ), power supplies, ordnance 
safety box, Launch Enable Unit (LEU), and RF 
distributor comprise the LPE. 


_The LSEQ monitors and controls warhead 
functions, missile operation, gyro temperatures, 
and launch cell environment. These functions 
are broken into three distinct modes of operation: 
normal, preparation and test, and launch. Dur- 
ing the normal mode, the LSEQ maintains and 
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monitors the proper temperature and environ- 
mental conditions for the missile gyros. It will 
ensure that all door interlocks are properly 
closed, that umbilicals are mated, and that the 
missile is in a state of readiness to accept the 
preparation command. It also will indicate to 
the DPS missile monitor that all conditions are 
correct. If they are not, the LSEQ will generate 
a minor alarm. 


When a missile subsystem is in the normal 
mode, it will accept the preparation order from 
the DPS at any time. Once the preparation order 
has been received, the LSEQ will begin to warm 
up the missile. Warmup is accomplished by ap- 
plying missile ground power, spinning up the 
gyro, and aligning the roll platform, At the com- 
pletion of warmup, the LSEQ will generate the 
RF Test Request (RFTR) indicating to the DPS 
that the missile is ready for testing and/or launch. 


Upon receipt of the RFTR, the DPS will gener- 
ate either the RF Test Order (RFTO) or Launch 
Orders (LOs). If the DPS orders the missile 
to be tested via RFTO, the MSR will transmit 


-RF commands to the LPE RF section via the 


radar beam in the case of the collocated farm 
or via cable for the remote farms. During the 
testing phase, the LSEQ will test approximately 
97 percent of the autopilot electronics and 98 per- 
cent of the MGS electronics. When the RF test 
phase of the preparation period is successfully 
completed, the LSEQ will generate the ready 
status signal indicating to the DPS that the mis- 
sile has completed the test and is ready to be 
launched. If the test phase is not successful, the 
LSEQ will generate a major alarm. The DPS 
then has the option to either retest the missile or 
restore the subsystem to normal. 


Nuclear weapons can only be used upon presi- 
dential authority and SAFEGUARD is released 
through the North American Air Defense Command 
(NORAD) at the Cheyenne Mountain Complex. 

The release information is transmitted in coded 
form over a data link to the Missile Defense Cen- 
ter (MDC) where the message is decoded and the 
contents displayed on a system status display. 
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A second message is then originated within the 
Launch Enable (LE) equipment as the first part of 
a chain of events to effect a missile launch or a 
system test. The elements of the second mes- 
sage pass through the Launch Enable Message 
Transmitter (LEMT) to the Launch Enable Mes- 
sage Receiver (LEMR) and then to the Launch 
Enable Transmission Set (LETS). Finally, the 
message is fanned out to Launch Enable Coded 
Switches (LECs) located in each of the missile 
launch cells. Receipt of a properly coded message 
by the LECSs produces a condition which permits 
missile launch orders generated by the DPS to 
pass to the missile. The LE equipment monitors 
and reports operating faults and status within 
each LECS, 


After RFTR or ready has been generated by 
the LSEQ and the LE signal has been received 
by the launch enable coded switch, the LSEQ 
will accept launch orders to initiate the sequence 
which applies fire signals to the Launch Eject 
Gas Generator (LEGG). Between the receipt of 
LOs and ignition of the LEGG, the flight bat- 
teries are activated and checked, the control 
systems are activated and checked, the one- 
shot ordnance is fired, the umbilicals are re- 
tracted, etc. Failure to accomplish any of 
these operations will cause the LSEQ to abort 
the flight. Once the missile has been fired, the 
LSEQ will generate the missile-launched signal 
and after a short period of time, it will shut 
down removing all power from the launch 
station. 


Remote Launch®#! 


The SPRINT remote launch equipment, shown 
in Figure 9-6, allows communication with the 
SPRINT missiles emplaced in remote missile 
farms up to 25 miles from the Missile Site Con- 
trol Building (MSCB). The function of the remote 
launch equipment is to enable remotely located 
SPRINT missiles and launch preparation equip- 
ment to communicate with the DPS for preflight 
testing and launching of missiles. This com- 
munication is accomplished via three two-way 
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redundant crypto data links to each remote 
SPRINT missile farm for (1) missile command 
and beacon responses (C/B link), (2) LPE 
orders and status (O/S link), and (3) Launch 
Enable signal and RLE status (LE link). 


The Remote Launch Equipment (RLE) receives 
missile commands from the DPS in digital form, 
transfers the data to the remote farms, and then 
transmits the missile commands as modulated 
RF signals to the missile LPE. The missile 
beacon pulse is received by the RLE, processed, 
and then transmitted to the DPS in digital form. 
The second data link receives LPE orders from 
the DPS in digital form and transmits data to the 
remote farms where they are converted into dc 
voltages for LPE operation. The de LPE status 
information is received by the RLE, converted 
to digital form, and transmitted to the DPS via 
the return path of the order and status data link. 
The third data link transmits the remote launch 
enable signal in digital form to each of the re- 
mote farms where the signals are converted into 
a format used by the launch enable coded switch 
at each SPRINT launch station. The return 
portion of the launch enable data link transmits 
remote launch equipment status to the MSCB. 


Ground Support Equipment 


The Ground Support Equipment (GSE) consists 
of all the equipment necessary to maintain and 
support the launch station, launch preparation 
equipment, and missile. 


The Fault Locator (FL) maintains the LPE and 
its associated cables by fault isolation to readily 
replaceable assemblies such as power supply, 
LSEQ, RF distributor, interconnecting cables, 
and missile sections. The FL receives a test 
enable signal from the DPS permitting the opera- 
tion of the FL at the launch station and verifying 
all operational functions of the LPE., The mis- 
sile is disconnected and replaced by the FL and 
all ordnance circuits are bypassed by FL cable 
interface during all FL operations. The FL ex- 
ercises the LPE through normal, preparation, 
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ready, and launch modes to verify timing and 
performance functions. The FL is transported 
and housed for operation in the SPRINT Service 
Vehicle (SSV). The RF Test Set, which is used 
to verify the operation of the LPE RF distributor, 
is also transported by the SSV. The Electrical 
Circuit Test Set (ECTS) tests various missile 
networks and performs no-voltage ordnance 
safety tests as part of the installation and/or 
maintenance of missile sections. The SSV is 

a self-contained, environmentally controlled 
vehicle used to handle, transport, and install 
the SPRINT warhead section, guidance, and 
nose cone assembly of the missile. In addition, 
the SSV transports and stores the spare LPE, 
FL, RFTS, and ECTS which are used for main- 
tenance of the missile, launch station, and 
LPE. The SSV carries its own weather shield 
and heating, cooling, and humidity control sys- 
tem to maintain a conditioned environment in the 
launch station during missile and/or LPE main- 
tenance and handling operations. The SSV also 
carries missile sections and LPE handling fix- 
tures used during either missile section or LPE 
replacement at the launch station. 


The Universal Transporter Loader (UTL), 
shown in Figure 9-7, is a tractor-trailer 
vehicle used to load and unload the SPRINT 
first- and second-stage Propulsion and Control 
Assemblies (PACAs) at the launch station, and 
to transport the PACAs to and from the Uni- 
versal Missile Assembly Building (UMB). The 
UTL is also used for all SPARTAN missile 
section installations or removals. An environ- 
mentally controlled housing for the missile sec- 
tion is mounted on the trailer of the UTL and is 
erected over the launch station for missile 
loading/unloading.8 


Included with the GSE are all missile loading 
and handling fixtures located at the UMB.™ 
These fixtures facilitate the loading, unloading, 
and assembly of missile sections at the UMB. 
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SUBSYSTEM DEVELOPMENT PROGRAM 
Propulsion 


Early parametric performance studies deter- 
mined that the overall missile conformation 
should be conical. Materials studies indicated 
fiberglass filament was the preferred motor case 
structural element to attain low inert mass frac- 
tion, while the maneuver requirements (and con- 
trol response) of the missile and their resultant 
bending stresses dictated the thickness of motor 
case walls. Once the minimum wall thickness 
was established, maximum operating pressure 
of the motor became calculable. It was desirable 
to operate the motor as near maximum pressure 
as practicable, because higher pressure pro- 
duces higher specific impulse. 


Quick missile reaction meant rapid launching 
and ignition with resultant high shock levels, 
High acceleration resulted in tremendous axial 
loads during first-stage burning while abrupt 
maneuvers developed high side loads. Thus, the 
propellant to be developed had to have excellent 
physical properties. It was necessary to have a 
high propelient mass rate of discharge to attain 
the high acceleration and velocity levels required 
of the missile. Also, a decision was made to use 
the same propellent on both stages for ease of 
manufacture. 


Propellent composition development was con- 
centrated on casting powder types containing fine 
Ammonium Perchlorate (AP) and a small amount 
of aluminum in the form of "staple" or chopped 
foil, There was experimentation with several 
burning rate catalysts, but none produced suffi- 
cient effect to warrant their use. High concen- 
tration Nitroglycerin (NG) solvents were also 
tried, but the sensitivity increases with the in- 
crease of NG. This was demonstrated by an un- 
fortunate incident in the Polaris program, which 
caused a limitation in the amount of NG in the 
solvent to be enforced early in the program. 


WEATHERSHIELD STORAGE 
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' Figure 9-7. Universal Transporter Loader 








A large increase in burning rates had initially 
been demonstrated as possible by the introduction 
of aluminum staple into the formulation, and a 
substantial effort was launched to optimize the 
staple dimensions. Aluminum content was lim- 
ited to a low percentage in the final formulation 
to decrease the possibility of afterburning in the 
plume, and thus minimize ionization in the com- 
munication path to the missile. It was found that, 
although use of staple-aided heat and flame prop- 
agation made high burning rates possible, the 
size of the AP particles was also a significant 
factor. The ability to fine-grind the AP in a con~ 
trollable and measurable fashion was the final 
key in allowing a suitable composition to be for- 
mulated in a repeatable way. 


Large conical pressure vessels had never 
been filament-wound, and the high operating 
pressure introduced another unknown design 
problem for fiberglass pressure vessels. The 
helical winding pattern chosen to carry the axial 
loads was alternated with hoop windings to carry 
girth loads. Since girth loads were higher at the 
larger end of the 4-degree half-angle conical 


' frustrum, more hoop windings were used at the 


larger end, and as successive hoop windings 
were added, they were terminated closer to the 
large end of the case; thus, a slightly tapered 
wall thickness was formed. High allowable hoop 
and helical stresses were attained in the glass 
filament windings. 


To allow attachment of the motor cases to the 
aluminum structure of the other missile sections, 
fiberglass attachment stubs were fabricated from 
a combination of glass cloth and glass filament 
windings and bonded in place on the pressure 
vessels, Although the bonded stubs were thought 
to be structurally sufficient, tests showed that 
the variables of materials and, especially, man- 
ufacture made it impractical in the time available 
to design and develop a purely bonded joint to 
carry the large axial loads and the bending loads, 
resulting from both internal pressure and pitch- 
over maneuvers. Accordingly, two rows of steel 
bolts were added to both forward and aft stubs of 
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the first-stage motor and to the rear stub of the 
second-stage motor to clamp the bonded stubs in 
place mechanically. No bolts were added to the 
forward end of the second stage, because the 
number of glass filaments to be cut in drilling 
holes for bolts would have weakened the structure. 


The first-stage motor was designed with inert 
slivers under each of the six star points in the 
grain to allow design of a web with near-uniform 
thickness. A uniform web allows simultaneous 
burnout throughout the combustion chambers and 
thus an abrupt termination of thrust. Burning 
time was closely controlled and made predictable, 
which, in the case of first-stage flight, facilitated 
staging and first-stage case separation. In early 
designs of the first stage, wires from the for- 
ward end of the missile to the controls at the aft 
end of the first stage were passed through the 
interior of the motor under the inert slivers. 
Unfortunately, during hydrotest of the case, 
water was forced into the wiring insulation and. 
caused subsequent electrical test shorts. Wires 
were then run on the exterior of the motor case. 


Initially, the inert slivers extended not only 
through the main body of the vessel, but also 
curved into the domes at each extremity. Unfor- 
tunately, the elastic properties of the glass- 
microballoon filled slivers were not good enough 
to permit sufficient bending in the dome regions, 
and sliver cracks occurred during combustion 
pressurization. Crack propagation into the pro- 
pellant permitted flame to reach the fiberglass 
and to burn through the wall. Slivers were rede- 
signed to eliminate the curved ends. 


The most serious propulsion development dif- 
ficulty was a casting problem which affected the 
grains of both the first and second stage, because 
they are cast in the same manner, SPRINT 
motor propellant is made by using large quan- 
tities of base grain or powder which contains all 
of the solid ingredients, and by packing a motor 
case with base grain and adding solvent to poly- 
merize the ingredients and bond the whole to the 
case wall. The process used sometimes allowed 
insufficient powder, but an excess of solvent, to 


collect under the forward dome. The result was 
soft propellant or voids under the dome, The 
problem was first suspected after failure of a 
Propulsion Test Vehicle (PTV), the second 
vehicle flown at WSMR to test propulsion, stag= 
ing, and the heat shield. The problem was 
temporarily _solved by cutting about 50 pounds 
of propellant in the forward end of the second 
stage and inhibiting the burning of the machined- 
propellant surface by bonding three layers of 
Buna-N rubber over it. The first guided and 
controlled SPRINT missile flew successfully 
with a second-stage motor of this configuration. 
Later in the program, when the problem mani- 
fested itself in the first stage, a similar tem- 
porary change was instituted. In the meantime, 
the inner surface of the forward insulation was 
changed, casting methods were modified, and 
both stages were thereafter successfully cast 
without encountering either the soft propellant 
or the need for the inhibitor. 


Another problem in the propulsion program 
concerned the ability of the motors to withstand 
shock during transport. At first, the problem 
centered around two motors which blew up during 
static firing, and much later, a missile which 
exploded over its launch station during the early 
phase of a flight at KMR. The early failures 
occurred as a result of motors which had been 
test-dropped and then fired in an attempt to show 
their capability to sustain the shocks experi- 
enced — shocks which were selected to represent 
'tworst-case" handling drops. The KMR failure 
generated concern that solution of the early prob- 
lem had not been complete. Subsequent exhaus- 
tive investigation alleviated that concern, and 
showed that the motors were indeed very rugged 
and could withstand considerable punishment 
without detrimental effects. 


To start at the beginning — part of the motor 
qualification program required that four sets of 
motors in their shipping containers be subjected 
to drop tests simulating worst-case handling 
shocks. This qualification requirement was 
regarded as routine, because analysis had 


shown that the motor had ample design margin 
over any stresses or strains which would be 
encountered. Furthermore, by the time the drop 


‘tests for qualification motors were made, many 


sets of motors had been shipped in wooden R&D 
shipping crates to Orlando and then to WSMR. 

In fact, several had made more than one round 
trip. No flight problem that could be traced to 
transportation and handling shocks had occurred. 
Thus, confidence and the desire to save time 
and money led to performing drop tests of both 

a first-stage motor and a second-stage motor 

in their separate containers before either was 
static-fired. Both motors blew up during firings 
on their test stands. 


Although analysis showed no cause for either 
failure, the conclusion was reached that im- 
properly fitting wooden supports in the shipping 
container had induced greater strain than had 
been predicted. The shipping containers were 
then redesigned to assure much better support 
for the motors. One first-stage and one second- 
stage motor in their respective new containers 
were then subjected to individual test drop se- 
quences, and both were successfully static-fired. 


In the meantime, a new directive required 
that motors shipped for deployment be assem- 
bled into a single unit containing the first- and 
second-stage motors and their control sections. 
Containers were then specifically designed to 
hold the propulsion and control assembly in a 
single package. A set of motors in this new 
assembly configuration and in the new container 
was then subjected to the qualification test drop 
sequence. Again, both motors were static-fired 
successfully. 


To complete the planned qualification test 
program, two more sets of motors were drop- 
tested and both sets were shipped to KMR for 
flight tests. Immediately after the first of these 
missiles was launched, the first stage of the 
missile ruptured near the launch station. Failure 
investigation concluded that the probable cause 
was a weakness induced by the drop tests. 
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The second set of dropped motors was re- 
turned from KMR, the motors and their support 
systems were heavily instrumented, and a com- 
pletely new set of drop tests was carried out with 
the same hardware. A new finite element analy- 
sis of the motor was conducted, and the values 
registered by the many strain gauges and accel- 
erometers used during the instrumented drop 
tests were used as inputs for the new stress 
analysis. 


Again, theory showed that the design allow- 
ances throughout the motor structure, case bond, 
and grain gave ample margin to withstand the 
shocks sustained. No damage to the motor could 
be found by any method used in the various exam- 
inations. The motors were then static-fired. 
Both were successful. 


The conclusion was reached that if the motors 
were manufactured to the design specifications, 
they could stand the specified shocks that the 
qualification program imposed. Failure of the 
first-stage motor at KMR apparently was caused 
by manufacturing or material weakness, perhaps 
aggravated by the shocks suffered during the 


‘drop tests. 


“In contrast to the results of the qualification 
drop test series, two other static motor test 
series dramatically demonstrated the strength 
of the pressure vessels. Prior to being loaded 
with propellant, each pressure vessel was hydro- 
tested to a pressure level 6 percent above its 
nominal peak operating pressure. The attach- 
ment stubs were subjected to both axial and 
shear loads which simulated normal propulsive 
forces and maximum maneuver loads. Some 
pressure vessels were also burst-tested to 
demonstrate their ultimate strength. 


To further demonstrate safety margins, two 
first- and two second-stage motors were fired 
with throats machined to diameters slightly 
smaller than normal. Peak operating pressures 
were 15 percent above normal and no failures 
resulted. 


Another design objective for the SPRINT 
motors was a long tactical life. Two motors 
were set aside for aging studies.5 After approxi- 
mately five years, one set of motors was used 
successfully at KMR. The other motor was suc-~ 
cessfully static-fired at Allegheny Ballistics 
Laboratory after aging for 7-1/2 years. 


First-Stage Control System 


Thrust Vector Control (TVC) was chosen to 
provide pitch and yaw forces during first-stage 
flight to attain fast response to initial turn orders 
and command maneuvers. Freon was chosen as 
the injection fluid because of experience gained 
with its use in both Polaris and Minuteman, even 
though SPRINT required a much higher flow rate. 
Initial development was started on two parallel 
paths: one using a fixed valve body and three 
movable pintles, and the other using three fixed 
pintles and a movable body. The movable pintle 
version was finally chosen when it appeared to 
involve fewer problems. 


The TVC system, as initially designed, used 
Freon as both the injected fluid and as the work- 
ing fluid for the servo-actuator assembly which 
controls pintle motion. The hydraulic fluid 
used as the working fluid in the servo actuator 
during ground testing was displaced with Freon 
during flight. Unfortunately, the two hetero- 
geneous fluids caused variations in fluid density 
in the servo-valve nozzle and flapper area, and 
servo-valve performance was erratic. The 
problem was resolved by adding hydraulic fluid 
accumulators to the system to provide a separate 
and uniform hydraulic oil servo-actuator fluid 
throughout first-stage operation.* 


Another modification to the hydraulic fluid 
system was added after early flights at WSMR. 
Data indicated that acceleration forces on the 
hydraulic fluid could partially deplete the actua- 
tor cavity during launch eject, and the temporary 
lack of fluid could cause delay in transmission of 
a TVC command. Effective with missile FLA-7, 
a stand-pipe was added to the overboard dump 


line of the valve to counterbalance the fluid 
mass ‘in the valve and actuator. 


The pistons in the four Freon accumulators 
and in the two hydraulic fluid accumulators are 
pressurized with gas generated by an ammonium 
nitrate propellant. Because of the rapid ignition 
and pressure buildup requirements, the propel- 
lant is cast in four concentric annuli to provide 
the large burning area needed. The thin cylin- 
drical annuli gain their strength from an epoxy 
binder. Although the propellant mixture was 
adapted from that used in gas generators to open 
covers over Minuteman silos, the manufacture of 
propellant in a repeatable process proved to be a 
difficult goal. Specified performance was met 
through very careful engineering and strict 
quality control standards. 


The manifold conducting the hot gas from the 
gas generator to the Freon tanks was initially 
made of René 41 (a Columbian nickel alloy) with 
an inside coating of Avcoat as insulation. René 
41 was selected because of its strength at the 
chosen design temperature. However, the alloy 
was difficult to weld, and the large amount of 
welding required for the manifold configuration 
made material rejection rates high and fabrica- 
tion very expensive. The Avcoat insulation was 
applied internally in a liquid form and tended 
to be thinner in the vicinity of manifold junctions 
where insulation thickness was especially crit- 
ical. A flame-sprayed coating of copper was 
applied over one critical area as a temporary 
expedient to conduct heat away from the load- 
carrying material. The final solution was to 
change the manifold material to 4130 steel with 
an inner sleeve of silica phenolic insulation 
Slipped inside in sections and fitted and bonded 
at the various manifold branches and junctions. 


Second-Stage Control System 


The heart of the second-stage control system 
was a hot gas-driven motor pump which had been 


well along in development for the Skybolt missile. 


The selection of this particular pump made pos- 
sible the design of a lightweight closed hydraulic 
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system with fast response. The design of the 
motor pump allowed the missile flight time, and 


_ hence the operating time of the pump, to be in- 


creased by a factor of two. However, thermal 
considerations resulting from the extended ex- 
posure to hot gas indicated several changes. A 
forced lubrication system was added to the motor, 
and breakable inlet and exhaust seals were added 
to retain lubricating oil in the motor housing dur- 
ing storage. The motor housing was changed 
from cast aluminum to steel to lessen warpage, 
and the piston-to-bore clearance was increased 
to prevent scuffing or seizure : 


Use of this particular pump size, important 
because existing Skybolt technology could be 
transferred directly, was made possible by in- 
corporating a stepped piston in the air vane 
actuators. The piston arrangement, which has 
an area ratio of about 2.4 to 1.0, permits the 
larger area to be used to provide the required 
torque during periods of high vane loading, and 
allows the smaller area to be used when the vane 
torque requirement is low but the duty cycle is 
high. A hydraulically operated selector valve 
attached to each vane actuator directs flow to 
the proper actuator area on command from the 
autopilot. 


The hot gas generator for the second stage 
was a source of more difficulties than the first- 
stage gas generator and required constant atten- 
tion, not only throughout development, but also 
throughout the production phase. These problems 
included the propellant mix, casting, ignition, 
burning-rate catalyst, materials storage, mois~- 
ture, contamination, and quality control. Most 
of the difficulties related to the ammonium 
nitrate, which undergoes crystalline-structure 
phase change at 90 degrees Fahrenheit with a 
consequent change in its specific volume. This 
temperature line is crossed and recrossed during 
mixing and casting, as well as in the normal 
storage and shipping of gas generators. Ammo- 
nium nitrate crystal shrinkage can cause micro- 


‘scopic voids throughout a grain, and burning 


rate increases because of increased exposed 
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surface. Grain dimensions were seen to change 
with age, and the initial gap width between the 
free-standing grain and the case wall changed. 
(The case-loaded grain must be bonded on one 
end only to allow expansion without crushing 
during burning.) 


One missile, FLA-30, lost second-stage con - 
trol when hot-gases from its end-burning grains 
penetrated around the circumference of one grain 
so as to burn through the wall of the metal case. 
Thereafter, great care was taken to measure the 
gap between grain and case wall on radiographs 
of assembled units. A study was also started 
to learn more about changes in this gap dimension 
with age of the gas generator. Repeated radio- 
graphs were made to determine that grain size 
had stabilized. 


As with the first-stage gas generator, second- 
stage gas generator development and production 
were successful only because of careful, con- 
stant engineering surveillance and frequent, full 
interchange of information between the subcon- 
tractors and the system contractor. 


- Heat Shield 


Thermal protection for the body of the missile 
was envisioned as one of the major development 
problems. Boundary layer temperatures were to 
reach peak values of thousands of degrees Fahr- 
enheit, and the aerodynamics which determined 
temperatures and regions of most severe expo- 
sure were not well understood. No missile had 
ever flown at this speed in the dense atmosphere. 
Wind tunnel tests at the Air Force Arnold En- 
gineering Development Center and at NASA 
Langley, together with analyses, provided the 
early thermodynamic models on which material 
selections were based. There were no ground 
test facilities that could simultaneously produce 
the flow velocity, dynamic pressure, and heating 
rates expected for the SPRINT vehicle. 


The General Electric Malta Test Center pro- 
duced realistic heating rates for relatively long 
periods of time using the exhaust from a liquid 
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rocket motor. Tests in this facility were 
valuable for selection of materials for the missile 
forebody and air vanes even though the tempera- 
ture and dynamic pressure were limited. Nose 
tip tests were conducted in the Cornell Aero- 
nautical Laboratory Wave Superheater, where 
intense heat pulses could be produced with 
relatively high stagnation pressure and heating 


rate for a very brief time period. Specialized 


tests were also run in the Martin FLAME facility, 
which produced a severe thermal environment 
using the exhaust from a solid rocket motor, -and 
at other test centers, but there was no facility 
that could provide a real composite thermal test 
environment.” Accordingly, a program to fly 
Material Test Vehicles (MTVs) was conducted 
by quickly fabricating and flying a simple two- 
stage vehicle using excess solid propellant 
Recruit and Cherokee motors. The environment 
in this test approached the velocity, dynamic 
pressures, and heating rates expected on the 
final SPRINT design. The recovered MTVs 
showed satisfactory response for the silica 
phenolic nose cap, the tape-wrapped silica 
phenolic heat shield over the body, and two 
molded silica phenolic air vane leading edges. 


The first opportunity for a realistic test of the 
thermal barrier came in March 1965, with the 
successful flight of the first SPRINT air frame 
Propulsion Test Vehicle (PTV-1). This ballistic 
flight produced an aerothermodynamic environ- 
ment which virtually duplicated that expected of 
a controlled SPRINT flight to its primary design 
point. This experiment showed that a lightweight 
heat shield fabricated almost entirely of silica 
phenolic could keep the aluminum substructure 
below the required temperature limit. The proof 
of the heat shield design was an R&D SPRINT 
missile test flight at WSMR in June 1968, which 
was programmed to experience thermal environ - 
ments in excess of the design maximum. Erosion 
rates on both the nose cap and the air vane lead- 
ing edge were less than predicted, and perform- 
ance of the body heat shield was completely 
satisfactory. 


However, there were development problems 
with the heat shield, particularly that portion 
over the second-stage motor pressure vessel. 
The fiberglass vessel expands slightly when it is 
pressurized, and the heat shield must do the 
same. Although rubber was added to the phenolic 
matrix to allow sufficient elasticity, the bond be- 
tween the heat shield and the motor case did not 
always hold, partly because ofan aluminum foil 
shield for protection against Electromagnetic 
Pulse (EMP) between the heat shield and motor 
case. The EMP shield installation was modified, 
but real help also came through a slight thicken- 
ing of the heat shield occasioned by the increase 
in time of flight mentioned earlier. 


EMP protection of the missile caused another 
problem which was not recognized until the loss 
of FLA-52 at KMR. Investigation concluded that 
failure occurred because of an improper bond be- 
tween the heat shield and the structure at the 
leading edge of the second-stage motor. High- 
velocity air entered the gap at the interstage 
splice, found a small unbonded region under the 
Silica phenolic material, and apparently tore off 
the heat shield exposing the fiberglass of the 
motor pressure vessel. It was then recognized 
that the FLA-8 failure at WSMR had probably not 
been properly diagnosed; its failure had the same 
signature as that of FLA-52. The problem orig- 
inated with the requirement that the missile body 
provide a shield by being conductive throughout 
its length. Asa result, the aluminum EMP 
shield over the fiberglass motors was bonded to 
the aluminum splice ring with a special copper- 
loaded conductive bond material. Applying the 
copper-loaded material evenly was difficult, and 
the heat shield leading edge sometimes puckered. 
A slight modification in which the leading edge of 
the heat shield was chamfered and covered with 
mylar solved the problem. 


One of the necessary heat shield design con- 
siderations was the requirement of flying through 
impacting rain. Sled tests on portions of the mis- 
sile were conducted at Holloman Air Force Base 
at speeds up to 6600 feet/second through a shower 
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system which simulated a rainfall rate of 4.6 
inches per hour. Other smaller scale tests were 
conducted at the Naval Ordnance Laboratory 
(NOL) 100-foot Hyberballistic Range. Data from 
Holloman and from NOL were used to construct a 
mathematical model which predicted erosion as a 
function of rain density and missile speed, .and 
erosion for flight through thunderstorms for typ- 
ical SPRINT trajectories. Results showed that 
SPRINT was well-designed for rain resistance. 


Autopilot" 


The initial autopilot design did not fulfill the 
philosophy of “tactical design" on the first flight, 
because the necessary information on body- 
bending frequency and missile flight response to 
commanded maneuvers was not known. However, 
the first autopilot design was complete and had 
full-flight capability. Significant changes reflec- 
ting flight data and new requirements were incor- 
porated at three points in the program as "Mod" 
changes. 


The Mod I autopilot design, effective with 
FLA-5, had modified compensation to improve 
stability at low dynamic pressure. This design 
generally met all the tactical requirements, but 
analytical studies with flight data indicated that 
the stability could be greatly improved if both the 
gain and compensation were made to vary with 
dynamic pressure .4 


Thus, the Mod Ii design, effective with FLA- 
16, had compensation networks that varied 
with dynamic pressure, resulting in reduced 
extraneous vane motion and minimum hydraulic 
power consumption. The design was also more 
tolerant of variations in static margin (relative 
longitudinal displacement of the center of pres- 
sure and center of gravity). Interim radiation- 
hard circuits were introduced and improvements 
were made in the adaptive loop and in the filter- 
ing of control system disturbance induced by 
structural flexibility .~ 


The most significant group of changes was in- 
troduced with FLA-32 and designated Mod 1." 
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These changes provided for a remote launch cap- 
ability, improved radiation hardness, improved 
reliability, and easier autopilot installation. 
These changes also deleted the acceleration loop 
in the first-stage control circuits. 


Subsequent to the introduction of the Mod II 
autopilot, other changes were made. Shock and 
vibration exposure during Mod II design qualifi- 
cation tests produced broken solder joints"! 

This problem was corrected by stiffening the 
printed circuit multilayer boards, effective with 
FLA-33. Pitchover accuracy and TVC efficiency 
were improved by increasing the command dura- 
tion and eliminating a gain change during flight, 
effective with FLA-35. The wiring harnesses 
were modified, effective with FLA-40, to bring 
telemetry signals out to a special connector on 
the distributor and a telemetry buffer package 
was designed for mounting in the warhead sec- 
tion. With FLA-43, the ambient temperature of 
the electronics was reduced by changing the op- 
erating point of the rate gyros from 175 degrees 
to 145 degrees Fahrenheit, thus requiring the 
application of less heat. After a lengthy investi- 


_ gation, a number of changes were made to reduce 


possible interference with the free movement of 
the turntable due to contamination of the flotation 
fluids. Effective with FLA-67, the resolvers 
were encapsulated, lead wires were rerouted, 
and a higher torque spin motor for the rate gyros 
was provided. On FLA-80, a number of elec- 
tronic component changes were made to improve 
the nuclear radiation hardness. Beginning with 
the first production missile, components with 
greater radiation hardness were used and the 
bonding of the seismic mass of the accelero- 
meter was improved. 


Other significant design changes were made 
in the course of the program. After a failure 
in FLA-2, a capability for testing the interval 
timer was introduced for FLA-3. The servo 
amplifiers were modified to reduce the quiescent 
current and thus the internal heat. Flight fail- 
ure of FLA-5 was attributed to a broken gimbal 
balance pin in a rate gyro. Corrective action, 
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effective with FLA-7, ended this problem. 

Flight failure of FLA-18 led to mechanical de- 
sign changes to reduce the sensitivity to shock, 
and a shock test requirement was added to the 
acceptance test procedures. On FLA-25, voltage 
limiters were added to eliminate previously ob- 
served control signal oscillation during amplifier 
saturation. Investigation of a transistor failure 
on FLA-26 led to the discovery that detonation of 
the squib switches in the electronic control sub- 
assembly created excessive shock. ' Mechanical 
design changes were made to improve the isola- 
tion of these switches effective with FLA-27. 


Launch Eject 


When the missile is mounted in its launch sta- 
tion, the aft end of the first-stage skirt rests on 
a launch-eject piston. The missile itself is sta- 
bilized in its launch tube by one set of foam 
wedges near the missile midsection. A material 
change was made early in the flight program 
based on a lesson learned with FLA-3. When 
FLA-3 was given the launch order, it went 
through the standard automatic missile check 
series which precedes missile ejection, failed 
one test, and, consequently, did not proceed with 
ignition of the launch eject gas generator. How- 
ever, the missile-flight gas generators had al- 
ready ignited in their normal sequence and con- 
tinued to burn while the missile sat in the launch 
station. The exhaust of the second-stage gas 
generator ignited one of the urethane foam 
upper wedges, which burned and heated one or 
more of the bolts in the forward end of the first- 
stage motor. Enough heat was transmitted 
through the bolts to ignite the first-stage propel- 
lant. The resulting explosion destroyed both the 
missile and the launch station. The foam material 
was then changed to self-extinguishing Hetrofoam. 


Two environmental problems in the guidance 
section were caused by the launch-eject sequence.” 
One was a shock caused by the ordnance which 
was detonated to cut the fiberglass launch station 
closure just prior to missile ejection. Correc- 
tive action involved covering the guidance section 


with a 2-inch thick "shock sock" of flexible 
urethane foam to attenuate the explosive effect 
of the closure ordnance. The foam was backed 
by a leaded vinyl sheet and fiberglass cloth and 
four nylon lanyards were provided to cut the 
sock and remove it during launch. To dissipate 
the heat from the gyro heaters, the shock sock 
was slotted and attached to an air duct from a 
blower in the launch station. 


The second environmental problem in the 
guidance section was a higher-than-anticipated 
shock that occurred when the missile was 
launched and the nose cap slid over the opening 
where the ground power umbilicals had been con- 
nected. The situation was corrected by design- 
ing a hydraulic damping system in the nose cap 
slide tube. 


Another problem involved a large shock which 
reverberated through the missile frame from 
the rear of the missile during the ejection phase. 
The metal piston itself was retained in the launch 
station, but the high-pressure gas under the pis- 
ton escaped through holes in the side of the launch 
tube and was directed upward by the exterior wall 
of the launch station to impinge on the missile. 
The piston itself sometimes broke and ejected 
pieces became a menace. The Solution was a 
design modification to the interior of the launch 
station to cushion the upward motion of the piston 
against an arrestor assembly. The assembly ab- 
sorbed the energy in tubes filled with crushable 
aluminum honeycomb and formed a pressure seal 
to entrap the ejected gases until they could be 
bled away safely. 


Another launch problem emerged near the 
end of the WSMR flight program, causing failures 
of FLA-34 and FLA-36. The first failure was 
initially diagnosed incorrectly. After the second 
failure, investigation and careful camera cover- 
age during further launch-eject tests on dummy 
missiles_revealed another foam wedge problem, 
A refined analysis of wedge loads showed that 
the loads on the upper wedges during eject were 
critical because these wedges were designed to 
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guide the missile along the launch tube. Tight- 
fitting upper wedges located around the top of a 
first-stage caused eject-piston seal failures 
which caused the lower wedges, located around 
the circumference of the first-stage skirt, to 
buckle the first-stage skirt during launch. The 
lower wedges were relocated to serve as guide 
blocks on the piston, and the upper wedges were 
thereafter custom -fitted and shipped with their 
particular missile. 


Staging 

The successive flight failures of FLA-9 and 
FLA-10 in April and May of 1967 showed the 
presence of a staging problem. SPRINT was re- 
quired to undergo staging at dynamic pressures 
not experienced in other missile programs, and 
there were some surprises in the severity of the 
staging environment and its subsequent effects. 
Missile separation was required at different al- 
titudes and at different missile angles of attack. 
Also, the second-stage ignition in early flights 
was taking place while the first-stage case was 
still close enough to generate aerodynamic ef- 
fects on the second stage. 


Motion pictures, as well as available on-board 
instrumentation records, were studied closely to 
observe differences in separation phenomena be- 
tween successful and unsuccessful flights. Two 
static second-stage motor firings were conducted 
with instrumented spent first-stage cases at se- 
lected separation distances. Wind tunnel tests 
were conducted at the Air Force Arnold Develop- 
ment Center with two models, and other special 
experimental tests were run in other tunnels 
from August to December of 1967. The results 
were incorporated into a staging analysis. 


First, changes in timing of missile staging 
were made to allow drag to separate the first 
stage sufficiently before second-stage ignition. 
Second, a series of hardware changes was made. 
The second -~stage nozzle closure was strength- 
ened to prevent its implosion and the subsequent 
premature autoignition of the second-stage motor 
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by an unplanned entry of hot boundary layer air. 
The second-stage nozzle exit cone was strength- 
ened to prevent its being fractured, either by vi- 
bration, large bending forces, or debris. The 
second-stage flame shield around the nozzle was 
modified to attain proper restriction of nozzle 
bending and also to ensure protection of wiring 
and control components. Interstage connectors 
were modified to lessen the possibility of damage; 
and hardware, wiring, and instrumentation on the 
first-stage dome area were concentrated near the 
center of the motor closure. A maraging steel 
"derby hat" protector was securely bolted over 
all of these first-stage appurtenances to prevent 
debris from being created and possibly thrown 
into the rear of the second-stage either by bound- 
ary layer forces or second-stage motor plume 
forces. 


Three missiles were specially instrumented 
and flown at WSMR to assure proper identification 
of staging problems and their proper solutions. 
Measurements of the environment on these flights 
led to further changes. It had been initially 
speculated that vibration and shock environments 


-during flight would be extremely high, and design 


specifications for components demanded extreme 
ruggedness. Special accelerometers had to be 
developed because none were available to meet 
expected vibration, shock, and acceleration. 
After the specially instrumented "staging" flights 
produced a better definition of the flight environ- 
ment, it was realized that still further measures 
were necessary. Dacron-lacing of all wiring re- 
placed the harness ties, and brackets were 
strengthened. The autopilot frame and the foam- 
ing of its components were modified to increase 
the unit's ability to withstand the forces generated 
during launch, separation, and maneuver. 


FLIGHT TEST PROGRAM® 


Development flights were originally conducted 
at WSMR to recover and examine flight hardware. 
Forty-two SPRINT missions were flown there to 
provide tests of all SPRINT missile subsystems 
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in as many of the flight environments as possible. 
The flight program was then moved to KMR, 
where SPRINT was integrated with other com- 
ponents of the SAFEGUARD System for systems 
tests involving another 34 flights. All missiles 
flown were of the tactical design as shown in 
Figure 9-8. 


The broad objective of the flight test program 
was to verify that all subsystems could perform 
as designed to the extent demonstrable at WSMR 
and KMR. To meet this broad objective, it was 
necessary to verify that: 

e The propellant would survive the axial and 

lateral g-loads specified and would provide 
the required thrust to accelerate the mis- 


sile to effect intercepts within the specified 
time. 


e The heat shield would maintain its integrity 
under worst-case flight trajectories and 
would maintain the internal temperatures 
below specified limits. 


e The inertial sensors would survive the ac- 
celeration and shock loads during worst- 
case flight trajectories. 


e The first- and second-stage control systems 
would perform both within the required 
accuracy /time limitations and for maxi- 
mum flight time. 


e The communication link would be main- 
tained during all flight phases. 


e The launch station and ground support 
equipment would prepare and launch the 
missile within the specified interval, and 
would perform the required missile sub- 
system checks within the specified time 
periods. 

The WSMR flight test program demonstrated 
that SPRINT missile performance parameters 
were as specified in applicable documents.“ All 
performance requirements were achieved, veri- 
fying SPRINT missile readiness for the KMR 


system test program. 


The KMR test program was designed to gather 
data to support the evaluation of the tactical 
SAFEGUARD System. The KMR missions, from 
the SPRINT subsystem point of view, demon- 
strated the capability to launch and guide the mis- 
sile with the MSR and the MSDP to intercept a 
live or simulated reentry vehicle. Intercepts 
were accomplished well within required miss 





Figure 9-8. SPRINT Missile in Flight 


distances. In fact, one intercept resulted in 
physical contact. SPRINT compatibility with 
the SAFEGUARD System was verified and data 
were gathered to evaluate SPRINT subsystem 
performance. 


The system tests included the objectives of 
exercising the guidance/interceptor subsystem in 
engagements which tested the most stressed as- 
pects of system performance and of obtaining 
data to substantiate the SPRINT guidance model 
used in system evaluation simulations. For ex- 
ample, the extended range mission provided 
valuable data to more precisely define drag 
characteristics for simulation purposes. Critical 
intercept conditions of interest were: 

e Regions of low lateral acceleration capa- 

bility 

e Large crossing angles 

e Near vertical trajectories 
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e Low elevation angles 
e Long-range intercepts 
e Intercepts shortly after motor burnout. 


Significant accomplishments in the flight pro- 
gram included two successful flights through 
rain, a successful flight using aged first- and 
second-stage motors, successful performance of 
a cell closure after plume sweep from a missile 
launched from an adjacent cell, salvo launch cap- 
ability, and successful intercepts of reentry ve- 
hicles. The flight program also demonstrated 
successful interchangeability of missile sections. 


A summary of KMR (and WSMR) flight tests 
may be found in the Phase If Development Plan 
SPRINT Subsystem, Vol. IV, Table 1-I. For 
intercept points and field of fire, see Figure 
1-15 of the same reference, and for a summary 
of subsystem performance, see Chapter 1. 














In summary, flight test results both at WSMR 
and at KMR demonstrated that important missile 
performance characteristics were significantly 
better than those specified before the start of the 
development program. Missile subsystem in- 
flight reliability for the last 30 flights of the R&D 


. 
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program was very high, and design changes re- 
sulting from failure analyses have been incorpor- 
ated, so that deployed tactical missiles should 
meet the extremely high missile in-flight reli- 
ability objective. At KMR, the missile availa- 
bility exceeded requirements. 
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The role of SPARTAN in SAFEGUARD is to 
intercept ballistic missile targets at long range, 
with a large payload, in the exoatmosphere. The 
missile finally deployed at Grand Forks, North 
Dakota resulted from an extensive R&D effort 
which began in 1955 during the NIKE-ZEUS 
program. As requirements changed, SPARTAN 
evolved from a single-stage, hypersonic, winged 
antiaircraft missile, which was never built, 


‘ through three configurations of antimissile mis- 


siles (DM-15A, B, and C) to the present design. 
Originally designated DM-15X2 (ZEUS-NIKE X), 
this missile was named SPARTAN in January 
1967.1 SPARTAN is similar to the NIKE-ZEUS 
DM-15C configuration, modified to increase 
motor performance, improve missile guidance, 
and increase warhead yield. 


In January 1965, a nine-month study of the 
role of ZEUS in the NIKE-X System concluded 
that a ZEUS-type interceptor with a high-yield 
nuclear warhead would furnish a large-volume 
exoatmospheric kill capability against threats of 
interest. In March 1965, Bell Laboratories was 
authorized to proceed with Phases I and II of the 
R&D: defining the ZEUS missile subsystem based 
on NIKE-X system requirements and design 
trade-off studies, planning the development pro-~ 
gram, and completing the preliminary design. 


Phase III of the R&D program began in Oc- 
tober 1965 as formal design started and specific 
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Chapter 10. 
SPARTAN MISSILE SUBSYSTEM 


system and design trade-off studies continued? 
The principal parts of the program were (1) a 
29-month detailed engineering design, hardware 
fabrication, and ground test phase and (2) flight 
tests at Kwajalein and Meck Islands. An exten- 
sive functional and environmental test program, 
which included several months of system inte- 
gration testing in the laboratory, was carried 
out before the first flight test in March, 1968 

at Kwajalein. The R&D missile configuration 
reflected the basic approach of ''do it once; 

do it right"’ —the projected tactical design was 
built into the first flight missile and interim 
test missile designs were avoided. Thus, the 
flight test data on each major component were 
directly useful in the final design. Asa result, 
the missile development test program at Kwa- 
jalein consisted of only 15 missile flights. The 
first SAFEGUARD System flight test with a 
SPARTAN missile launched from Meck Island 
took place in April 1970. Twenty SPARTAN 
missiles were launched during the SAFEGUARD 
System test program, which was completed in 
June 1973. After that, five production missiles 
were flight tested during the Product Assurance 
Verification Test (PAVT) program. 


As shown in Figure 10-1, many agencies, 


organizations, subcontractors, and suppliers 
took part in the development of SPARTAN. 
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Figure 10-1. SPARTAN R&D Organizational Structure 
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MAJOR CHALLENGES AND INNOVATIONS 


Because it evolved from earlier designs, 
developing SPARTAN did not require new tech- 
nological breakthroughs. However, it did take 
determined and innovative engineering to produce 
a manufacturable design that functioned in the 
imposed environments with the specified availa- 
bility and reliability. Several facets of this 
effort were: 


1. Establishing a high reliability component 
program. Early in the development it 
seemed essential to establish a component 
procurement program under the strictest 
reliability procedures. The program 

* included a Bell Laboratories -approved 
list of high reliability parts from qualified 
vendors. It also included procurement 
specifications designed to ensure relia- 
bility that far exceeded the MIL speci- 
fications commonly used by the military. 
Each SPARTAN missile contains roughly 
10,000 high reliability electronic parts. 
This emphasis on ultra-high reliability con- 
tributed to superior SPARTAN perform- 
ance during the Meck flight test program .3 


2. The missile structure and all its sub- 
systems, including electrical components, 
had to withstand severe nuclear effects. 
The extensive program that achieved and 
assessed nuclear hardness has been thor- 
oughly documented.’ For more informa- 
tion on this program, see Chapter 6. 


3. Another SPARTAN. innovation was an 
ablator, which is lightweight and applied 
with spray heads while a missile sec- 
tion is rolled on its axis. During R&D 
flight tests at Kwajalein, the ablator 
proved it could protect the missile from 
the extreme heat induced by atmospheric 
flight. Special instruments were im- 
bedded in the ablator to determine the 
depth and rate of ablation. 


4. The Missile Guidance Set (MGS) developed 
for SPARTAN is essentially the same as 
the SPRINT MGS. It uses extensive 
foaming of subassemblies and a preload 
arrangement to ensure proper operation 
during severe shock, vibration, and 
noise. The MGS has a three-channel 
receiver, which monitors the signal 
received by three equally spaced pairs 
of missile antennas and automatically 
switches the beacon transmitter pulses 
to the antennas with the strongest re- 
ceived signal. This transmitter switch- 
ing feature, coupled with a hard limiting, 
instant response, intermediate frequency 
amplifier, lets the MGS detect and decode 
signals during the rapid fading caused by 
attenuation from missile plume and plasma 
sheath. 
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5. At first, a design based on discrete 
components was developed for the 
Launch Preparation Equipment (LPE). 
Later in the SPARTAN development 
cycle, Integrated Circuit (IC) technology 
which had become well proven, was 
shown to be more suitable for the LPE, 
especially from the standpoint of produc- 
tion costs. An Integrated Circuit LPE 
(ICLPE) design was introduced and 
proved to be highly reliable during flight 
tests at Kwajalein. 


6. The Sperry fluid-sphere gyro in the 
SPARTAN attitude reference unit was 
the first application of this unique de- 
vice in a major system. The concept 
of sensing pressure differentials be- 
tween a rotating fluid and its container 
produced a device more reliable than 
the conventional gyro, which senses 
gimbal axle displacements with rela- 
tively delicate sensors. 


7. Other innovations in SPARTAN included 
a sealed hydraulic control system and a 
quartz nose cap. The hydraulic system 
was found:to be very reliable during 
storage and in-flight operation, while the 
nose cap withstood worst-case natural 
environments.$ 


DESCRIPTION 


SPARTAN Subsystem Operation 


The SPARTAN subsystem consists of high- 
performance interceptor missiles, controlled 
by ground radar and armed with nuclear war- 
heads, plus associated ground support and 
launch equipment.! The missiles are deployed 
in a launch area near the Missile Site Radar 
(MSR) and emplaced in underground cells 
equipped with environmental control, testing, 
and monitoring equipment. Control and status- 
monitoring equipment are linked to the Mis- 
sile Site Control Building (MSCB). 


The three-stage, solid-propellant missile 
can intercept ballistic missiles at extremely 
high altitude and long range. The third-stage 
motor is normally used late in flight to achieve 
more accurate intercepts and to orient the 
warhead. As an option the motor can be used 
early in flight to extend SPARTAN's maximum 
range. The Missile Site Data Processor 
(MSDP) command guides the missile via the 


MSR link, and an onboard transponder generates 
short beacon pulses to help the MSR track the 
missile. 

At launch, a command from the MSDP ignites 
the SPARTAN first-stage motor and the motor 
lifts the missile from its underground cell. 
Ballistic flight is used during first-stage motor 
burning. The fixed first- and second-stage fins 
and the locked third-stage control surfaces keep 
the missile aerodynamically stable. At the end 
of first-stage burning, the second stage is ignited 
and its thrust forces separate it from the burned- 
out first stage. During second-stage flight, four 
movable control surfaces on the third stage 
aerodynamically steer the missile and control 
its roll rate.® 


The second stage burns out within the atmo- 
sphere after approximately 25 seconds of mis- 
sile flight, and the missile glides out of the 
sensible atmosphere. An MSDP command via 
the MSR can ignite the third-stage motor at any 
time after the missile leaves the atmosphere. 
Prior to intercept, the burned-out second stage 
. is separated from the third stage, which con- 
tains the warhead. Skin-cutting ordnance sep- 
arates the two stages shortly after the third- 
stage motor ignites,’ and ground commands 
control both the ignition and separation. Noz- 
zles in the rear edge of the third-stage con- 
trol surfaces vector the exhaust of the third- 
stage motor to control exoatmospheric reaction. 


To maximize warhead efficiency, commands 
from the ground properly orient the missile 
centerline with respect to the predicted intercept 
point before the third stage burns out.® The 
missile is then spin-stabilized to maintain this 
orientation until intercept.*” 


Missile 


SPARTAN's first- and second-stage motor 
cases are huilt of high-strength steel (see 
Figure 10-2). Monocoque aluminum construction 
is used in the first- and second-stage cylindrical 
guidance section and in the two-piece conical 
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Figure 10-2. The SPARTAN Missile 
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control section. There are three antenna 
strakes at the forward portion of the warhead 
section and three additional antennas mounted 
on the nose fairing. 


Ablative materials on appropriate sections 
of the missile skin dissipate boundary layer 
heat and limit internal missile temperatures. 
The three materials used are Teflon, * phenolic 
refrasil, and sparesyl. Teflon sublimes at high 
temperatures and is, therefore, used on the 
nose fairing and on the third-stage nozzle im- 
pingement pads.’ Phenolic refrasil is used in 
the third-stage fin area and on the leading edges 
of the second-stage fins. The remaining surfaces 
of the second and third stages are insulated with 
a lightweight albator called sparesyl. The first 
stage does not require insulation. 


The first and second stages are essentially 
propulsion units with stabilizing fins. The third 
stage contains the warhead section, missile guid- 
ance set,! flight control set, ‘! hydraulic pumping 
unit, third-stage motor, and four control sur- 
faces (thrust vector control). The missile guid- 
ance set receives steering orders from the 
ground and applies them to a flight control set 
to move the control surfaces through hydraulic 
servos.” Since the ground-based system ele- 
ments do not sense missile attitude, orders 
from the ground are sent in earth coordinates. 
These orders are then converted to missile 
coordinates by the stable reference system in 
the flight control set." The missile guidance 
set receives discrete commands, decodes them, 
and sends them to appropriate subsystems. 
These commands separate the third stage, start 
the third-stage motor, and control various war- 
head functions. 


*Trademark of E. I. DuPont de Nemours. 


TThis guidance equipment also is used in the 
SPRINT missile. See Chapter 9 for a des- 
cription of this unit. 
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The SPARTAN Hydraulic Pumping Unit 
(HPU) is shown in Figure 10-3. The gas gen- 
erator, consisting of an initial and terminal 
grain, sends a flow of gas tothe turbine. The 
flow rate depends on propellant formulation, 
chamber pressure, grain temperature, and 
grain geometry. The hot gas shutoff valve, 
which transfers from initial to terminal grain 
operation when required, functions in one of 
two modes of operation: the dwell mode, in 
which the initial grain has burned out before 
the valve is actuated, and the overlap mode, 
in which the valve is actuated when the initial 
grain is still burning. The operating gas 
pressure is controlled by the burn-rate control 
valve. 


Under steady-state conditions, oil flows 
from the pump to the accumulator, through the 
accumulator relief valve, then to the reservoir, 
and back to the pump. The accumulator is pre- 
pressurized at initial-grain ignition with nitro- 
gen released by the accumulator explosive 
valve. 


Under transient conditions (when the control 
surfaces are active), the accumulator furnishes 
oil to the control surface actuators via the 
regulator valve. The reservoir receives the 
return flow from the actuators. Under these 
conditions, turbine speed will vary as necessary 
to restore and maintain steady-state operating 
pressure in the accumulator. 


Launch Station 


The SPARTAN launch station (Figure 10-4) 
consists of a steel-lined launch chamber, 
exhaust duct, Launch Preparation Equipment 
Vault (LPEV), the Mechanical and Electrical 
Equipment Vault (MEEV), and the launch area 
antenna.” The launch station provides long- 
term storage for the missile, tests and launches 
it, and protects it and its launch and test 
equipment from natural and battle-induced 
environments.5:16 
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. Figure 10-3. SPARTAN Hydraulic Pumping Unit Assembly 
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Figure 10-4. SPARTAN Launch Station 
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MECHANICAL ELECTRICAL The launch chamber contains a launch rail 
' to support the missile in a ready-to-launch 
ANTENNA attitude. Associated with the launch rail is 


umbilical, the forward cradle capture equip- 
DPS J-BOX ment, the first-stage igniter mounting, and 


LAUNCH the High-Energy Firing Unit (HEFU).” A 
PREPARATION 
EQUIPMENT shock -isolation system in the launch rail 
eee attenuates nuclear or earthquake ground shocks 
18,19 
SPARTAN MISSILE to less than 1g. 


The launch chamber and exhaust duct are 
protected by two 2-piece cell covers (Figure 
10-5). The covers, each half weighing 4800 
lbs, are held closed by bolted plates. During 


plates and the cell covers are moved rapidly 
to an open position by a piston and cylinder 
attached to each cover half. Each cylinder is 
pressurized by a hot-gas generator ignited by 
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Figure 10-5, Launch Cell Protective Covers 


The MEEV and LPEV are located on the side 
of the launch station.” The MEEV, which is 
above the LPEV, houses the launch station heat- 
ing and air-circulation equipment and is reached 
through a submarine-type hatch cover. Air in 
the launch station is purged through the MEEV. 
The LPEV is entered through a hatch from the 
MEEV, and the launch chamber is entered from 
the LPEV through a blast door. The underground 
location and configuration of the LPEV shield 
it from nuclear and RF radiation.”4 


The Environmental Sensor Kit (ESK) is 
housed within the LPEV. In conjunction with 
remotely placed sensors, it monitors launch 
chamber and LPEV temperature, humidity, 
and water levels. An out-of-limits indication 
in an ESK sensor will generate a minor alarm 
which is transmitted to the MSCB via the Data 
Processing System Junction Box (DPS J-Box). 
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Launch Preparation Equipment Set 


The Launch Preparation Equipment Set 
(LPES), Figure 10-6, is composed of the 
Launch Preparation Equipment (LPE), 

DPS J-Box, and High-Energy Firing Unit 
(HEFU). All elements of the LPES except the 
HEFU are inside the Launch Preparation Equip- 
ment vault; the HEFU is at the bottom of the 
launch cell. The LPES is the functional link 
between the Data Processing System (DPS), 
the MSR, and the cell-emplaced missile. It 
prepares the missile for launch by testing the 
missile systems and monitoring critical mis- 
sile and launch cell support equipment during 
the preparation period, ready period, and 
launch sequence. It also supplies the missile 
with ground operating power for all tests until 
the missile is switched to internal power 
during the launch sequence. In addition to its 





Figure 10-6. Launch Preparation Equipment Set (Tactical) 


power and missile checkout function, the LPES, 
in conjunction with the DPS, can execute, in- 
terrupt, and recycle a preparation/RF test 
request at any time before the launch sequence 
starts. 


Nuclear weapons can be used only upon 
presidential authority, and SAFEGUARD is 
released through the North American Air 
Defense Command (NORAD) at the Cheyenne 
Mountain Complex. The release information 
is transmitted in coded form over a data link 
to the Missile Defense Center (MDC), where 
the message is decoded and the contents are 
placed on a system status display. 


A second message is then originated within 
the Launch Enable (LE) equipment as the first 
part of a chain of events that launches a 
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missile or tests the system. The elements of 
the second message pass through the launch 
enable message transmitter to the launch en- 
able message receiver and then to the launch 
enable transmission set. Finally, the message 
is fanned out to Launch Enable Coded Switches 
(LECSs) mounted in each of the missile launch 
cells, Receipt of a properly coded launch en- 
able message by the LECS permits missile 
launch orders generated by the DPS to initiate 
the launch sequence. During the launch sequence, 
the LPES generates signals that activate the 
missile launch order squibs, set the remote 
arm switch, activate the cell covers, and 
charge and trigger the HEFU for the first- 
stage ignition. 
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Ground Support Equipment 


The SPARTAN Ground Support Equipment (GSE) 
consists of field checkout and maintenance equip- 
ment, missile -handling equipment, and shipping 
containers. Some of the major items are: 


1. The Fault Isolation Test Set (FITS) is 
used toisolate failures and to verify LPE 
operation when a major alarm is received 
from a launch station. The FITS first 
tests the LPES to isolate the fault to 
either the missile or the LPES. Faults 
in the LPES are isolated to the drawer 
level of the LPE and to the unit level of 
the DPS junction box. Maintenance crews 
replace the faulty units and the FITS/LPE 
test is repeated to verify that the fault 
has been corrected. 


REAR 
LOUVER 





If the LPES works properly, it is as- 
sumed that the missile is at fault. First, 
maintenance personnel enter the launch 
cell and disarm the missile." Next, 
they remove the guidance/control section 
to gain access to the warhead section. 
The FITS and the LPE are used to test 
the warhead section functions. If a fault 
is detected in the warhead section, crews 
remove it and send it to the on-site war- 
head building for further testing.“.4 If 
no fault is detected in the warhead sec- 
tion, the guidance/control section is pre- 
sumed to be at fault and a spare section 
from the Universal Missile Building 
(UMB) is installed. Fault correction is 
then verified by the LPE. 


The Third-Stage Test Set (TSTS), Figure 
10-7, is used in the UMB and warhead 
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Figure 10-7. Third-Stage Test Set 


10-9 


buildings to functionally test the guidance 
section, control section, and warhead 
section interfaces. It can test third- 
stage ignition circuits, isolate control 
section faults, and isolate warhead 
section faults. 


3. The maintenance van, Figure 10-8, can 
transport the spare LPE drawers, the 
FITS, and maintenance tools. The 
maintenance van has a Shelter which is 
deployed over the entrance to the MEEV 
to allow access while protecting the 
missile from natural environments (rain, 
wind, and snow). 


An overhead electrical hoist in the van 
removes and replaces LPES components 
and transfers test equipment between 
the van and the LPEV. 


4. The missile-handling equipment includes 
all of the necessary fixtures, loading 
beams, and slings for assembling mis- 
siles at the UMB and at the launch sta- 
tion. It also includes the Universal 
Transporter Loader (UTL) shown in 
Figure 9-7 of Chapter 9. 


The UTL is a self-propelled vehicle that 
transports missile sections and loads 
them into cells. A weather shield pro- 
tects the cells from natural environments 
during missile-handling operations. 


SUBSYSTEM DEVELOPMENT PROGRAM 
~ Propulsion 


Development of the SPARTAN propulsion 
system started in April 1966. The effort was 
not extensive because the objective was to use 
NIKE-ZEUS technology as much as possible. 


SPARTAN's first-stage motor is almost 
identical to the NIKE-ZEUS DM-15C motor. 
The first-stage pressure-vessel design is iden- 
tical except for a change from special sandwich- 
rolled 4340 steel to cold-rolled 4340. This 
change resulted from improvements in steel- 
rolling techniques, which allowed use of the 
more economical cold-rolled sheet while re- 
taining high quality and close dimensional toler- 
ances. Other hardware changes were minor, 
and DM-15C's grain geometry was carried over 
to SPARTAN. SPARTAN also had an improved 
case insulation and a new propellent formulation 
that was common to the first and second stages. 
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The SPARTAN second-stage motor is a re- 
configured DM-15C first-stage motor. The 
steel motor case is the same, except-for the 
interstage connections and a larger port in the 
head end to accommodate the igniter. Both the 
propellent formulation and the grain configura- 
tion are new. A Carboxyl-Terminaied Polybuta- 
diene (CTPB) propellant with 87 percent solids 
was developed for the first and second stages. 
Since the Thiokol Chemical Corporation, which 
had the subcontract for the propellant, had 
extensive experience with the binder system and 
had done considerable research and development 
in high-total solids, a basic propellant formula- 
tion could be selected. The proper burning rate 
was reached and ballistic reproducibility was 
achieved by tailoring the oxidizer and fuel par- 
ticle sizes, optimizing their distribution, and 
determining the proper amount of burning-rate 
catalyst. Seven full-scale second-stage motors 
and one first-stage motor were all success- 
fully static-fired before the first flight test. 


The third-stage motor design is the same as 
that used in the NIKE-ZEUS DM-i5C missile. 


After the first successful missile flight, 
the propellant-liner interface was found to be 
separated in the forward opening of the second- 
stage motor. This problem occurred in 
several motors and reappeared after the mater- 
ial containing the original separations was 
trimmed out. The difficulty was first diagnosed 
as a tooling problem, but visible head-end 
separations and/or subsurface defects kept 
occurring after tooling changes. The problem 
was solved for the remainder of the develop- 
ment program by removing propellant from the 
area where separations were found and re- 
placing it with a cast-in-place burning-inhibitor 
boot. 


Near the end of the production program, 
massive propellant separations appeared in 
some second-stage motors in the same forward 
dome area behind the boot. The defect appeared 
only in some but not all of the motors cast from 
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a particular lot of raw materials. Since the 
defect was confined to one materials lot, and 
since none of the motors from that lot were 
needed to meet the reduced deployment re- 
quirements, it was decided by the Ballistic 
Missile Defense System Command (BMDSCOM) 
that no funds should be provided to further iso- 
late the prdblem. During this investigation, the 
effects of migration of the burning-rate catalyst 
were evaluated. It was found that the catalyst 
did not concentrate enough to impair the physical 
properties of the propellant-liner interface when 
the liner thickness was correct and proper cure 
time was used. 


_ One SPARTAN development flight, KT-05, 
failed in November 1968 because of propulsion 
problems. Although the exact cause could not 
be pinpointed, it was deduced that the second- 
stage nozzle exit cone bent with respect to the 
nozzle entrance structure, perhaps because of 
vibration, shock, or acoustic noise, and allowed 
gas to leak through the insulation. The exit 
cone support structure was stiffened, and there 
were no further problems.”’ 


In addition to SPARTAN motors used in other 
development tests, three sets of motors were 
given road tests, drop tests, and temperature 
cycling tests, in that order.2 One set of 
motors was ground-fired and the remaining two 
sets were flight-tested. All motors performed 
normally. 


Missile-Borne Guidance Equipment 


Development of dual-frequency Missile-Borne 
Guidance Equipment (MBGE) began early in the 
NIKE -X program. The MBGE mounted in both 
SPARTAN and SPRINT missiles was designed to 
operate with signals from either the Multifunc- 
tion Array Radar (MAR) on L-band or the 
Missile Site Radar (MSR) on S-band. The 
SPARTAN MBGE consists of a missile guidance 
set, six antennas, and interface cabling. At the 
outset, it was decided to design deployable hard- 
ware and not to go through an R&D phase followed 
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by a redesign for production. This approach 
saved many hours of dead-end engineering. 


After the MGS subassemblies (receiver, 
transmitter, decoder, and power supply”*) were 
breadboarded, two prototypes were built. One, 
which consisted of foamed subassemblies, was 
used for shock, vibration, and centrifuge test- 
ing, while the other was used for electronic 
testing. Both units were built with electronic 
components purchased with the special high- 
reliability procurement specifications. The 
high-reliability program started at the be- 
ginning of MGS development to ensure that a 
quality product would be deployed. To achieve 
an extremely low failure rate during MGS life 
(storage and flight), the number of component BS 
types on the approved usage list was minimized. 

Stringent component specifications weeded out i 
weak products. In many instances, specifica- 
tions included component burn-in tests. Before 

a component was authorized for the approved 

usage list, the vendor's production lines were 

extensively qualified, and a single source was 

established for each component type during the 

R&D program. The approved usage list of 

electronic components became a requirement 

for SPARTAN and SPRINT missile-borne hard- 

ware and launch preparation equipment. 


While the MGS was being developed, L-band 
and S-band missile antennas were designed and i 
fabricated. S-band antennas, which are used 
on both SPARTAN and SPRINT, must withstand 
the shock and vibration of flight and the extreme 
heat generated on the missile skin. To optimize 
antenna coverage, various missile-mounting 
geometries were tested on scale models and 
antenna pattern measurements were made later 
on full-scale sections.” A combination of 
three antennas forward and three midway down 
the missile proved optimum for SPARTAN, 
while three antennas forward worked well on 
SPRINT. s 


A transmitter output oscillator development 
program was also in progress while work on 
the MGS and antennas proceeded. During the 
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earliest part of the NIKE x development, work 
on an X-band magnetron design started. This 
design was abandoned in favor of L-band and 
S-band oscillators when the X-band mechanical 
radars of NIKE-ZEUS were replaced by L-band 
(MAR) and S-band (MSR) array radars. Several 
conceptual designs were started, including an 
integral tube and cavity and a pencil triode 

plus cavity, but the configuration finally chosen 
was the General Electric Company (GE) triode 
cavity oscillator. Besides meeting the stringent 
shock and vibration requirements placed on all 
MGS components, the triode cavity oscillator 
had a fast cathode warmup time that allowed 
quick missile reaction. This rugged unit was 
dropped from a second-story window to the 
parking lot pavement at GE and then brought 
back to the laboratory for test. It worked 
perfectly. 


Two missile guidance sets were built for 
missile interface tests and later used as a sim- 
ple way to exercise missile controls via an 
S-band link during flight simulation tests in the 
laboratory. With the successful conclusion of 


_ interface testing, missile-borne guidance equip- 


ment (MGS, antennas, cabling) was installed and 
checked-out in SPRINT flight missiles. The 
missiles were flown at the White Sands Missiles 
Range (WSMR) starting in November 1965. 


During the SPRINT flight program, a special 
circuit was installed in several missiles to 
divert the MGS transmitter pulse to the antenna 
facing the missile tail. With this special circuit, 
data were gathered on S-band attenuation from 
motor plume and hot skin plasma sheath. Both 
up and down links had sufficient signal-to-noise 
(S/N) margins after the worst-case (40 dB) 
attenuation induced by the plume and plasma 
was taken into account. About that time, MAR 
was replaced by the Perimeter Acquisition Radar 
(PAR) and a decision was made to communicate 
with the SPARTAN and SPRINT missiles only 
via the MSR. Therefore, effort on L-band 
equipment was terminated. 
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The MBGE worked very successfully through- 
out the WSMR (SPRINT) and Kwajalein Island 
(SPARTAN) flight tests. These development 
flights were followed by a highly successful 
SAFEGUARD System flight test program at 
Meck Island (SPARTAN and SPRINT). The 
MBGE, which contains approximately 5000 com- 
ponents, has a record of one failure in 114 flights. 
The MGS that: failed was recovered at WSMR and 
the trouble was isolated to a shorted capacitor. 
Special tests were added to the capacitor pro- 
curement specification to prevent future trouble. 
One MGS was recovered from the sand dunes at 
WSMR after a successful full-duration SPRINT 
flight test. When the missile was command- 
destructed at 40-kilofeet altitude, the MGS was 
blown free from the missile debris and tumbled 
through the atmosphere to crash into the ground. 
It was shipped back to Bell Laboratories, where 
it was powered up and given test commands. 

It decoded all discrete output commands and 
transmitted a normal S-band pulse with each 
test interrogation. 


Launch Preparation Equipment and Fault 
Isolation Test Set 

The SPARTAN development flight tests at 
Kwajalein (1968-69) and the early system tests 
from Cell 21 on Meck Island (1970) used modi- 
fied NIKE-ZEUS checkout and maintenance 
equipment. As a result of the SAFEGUARD 
deployment decision, more sophisticated, 
automated Launch Preparation Equipment (LPE) 
was developed for the tactical system starting 
early in 1968. 


A two-bay, twelve-drawer LPE with dis- 
crete high-reliability components was installed 
at Meck Island during the spring of 1970. Mis- 
siles were checked out and launched with this 
equipment starting that summer. During de- 
sign and fabrication, the advantages of con- 
verting the LPE from discrete electronic com- 
ponents to integrated circuits was studied. It 
was concluded that conversion would increase 
LPE reliability, reduce production costs, and 


improve maintainability. Design of the inte- 
grated circuit LPE started in the third 

quarter of 1970, with a first demonstration 
scheduled at Meck Island, Cell 22, during the 
last quarter of 1971. The LPE was reduced 
from a 12-drawer, 2-bay discrete version to 

a 5-drawer, single-bay IC version.?! During 
design of the ICLPE, the RF unit that interfaces 
the MSR and missile was redesigned and re- 
packaged for installation within the LPE. Prior 
to LPE redesign, the RF unit had been installed 
_ ina junction box on the LPEV wall. 


-Upon Nuclear Weapons System Safety Com- 
mittee (NWSSC) recommendations, the DPS 
junction box was redesigned beginning in early 
1972. This redesign incorporated: 


e Input-output cable isolation 
e Lightning surge arrestors on all cables 
to and from the launch station 


e Locating the Launch Enable Coded Switch 
(LECS) within a locked enclosure. 


A companion Fault Isolation Test Set (FITS) 
is used to troubleshoot the LPE. The FITS was 
redesigned to make it compatible with the IC 
version of the LPE. 


Studies and improvements in the FITS im- 
proved reliability in three areas: 


1. Certain logic cards within the FITS re- 
quired a wire-to-post welding technique 
that demanded tight production controls 
for a reliable connection. Refined welding 
and testing techniques were developed to 
ensure consistently reliable wire-to-post 
connections. 


2. Field and laboratory experience showed 
that tolerances for tests performed by the 
FITS were too tight. FITS/LPES test 
tolerances were relaxed to keep the FITS 
from rejecting a good missile. 


3. The FITS production design was modified 
to include high-usage integrated circuits 
and high-reliability diodes and relays. 
These components were already being 
used in the LPES. 

By incorporating these improvements, the 

overall reliability of the FITS was improved by 


50 percent. 
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Hydraulic System 


The basic elements of the NIKE-ZEUS hy- 
draulic system were used in the RED SPARTAN 
missiles, but a new tactical requirement — 
reliable Operation after five years of storage 
with no testing or repair — was placed on the 
design. This requirement dictated a fairly 
radical departure from previous systems, 
which were designed for periodic filling, check 
out, exercise, pressurization, and refurbishing. 
Successful development was anticipated be- 
cause** 


e Functional requirements had not changed 
significantly from the earlier NIKE- ZEUS 
configuration, and many components 
proven on the DM-15B and DM-15C mis- 
siles could be used. 


e Effort could be concentrated on repack- 
aging a known system to achieve reliable 
performance. 


e Standard materials and conventional tech- 
niques would be employed as much as 
possible. 


However, as development proceeded, it 
became evident that a very extensive engineer- 
ing effort would be necessary to achieve the 
high level of availability required after extended 
storage and the required high in-flight relia- 
bility.33. The most significant problems were: 


1. A first-stage servo valve failed during a 
flight simulation test prior to the first 
missile flight. When the valve was dis- 
assembled, a buckled plunger rod was 
found. Isolating the plunger rod from 
the hydraulic environment with an end 
cap on the first-stage servo valve did 
not completely solve the problem. Fur- 
ther testing revealed that a pumping O- 
ring in the housing created pressure dis- 
turbances via positive feedback, so addi- 
tional Teflon backup rings were added 
to eliminate axial clearances on the 
pumping O-rings. These changes elim- 
auated problems in the first-stage servo 
valve. 


tw 


Seized pistons in the hydraulic pump 
made the turbine overspeed when the 
first SPARTAN launch was attempted. 

’ The launch was aborted because of an 
unrelated prohlem, but the hydraulic 
system had already been activated and 
initially operated normally. Analysis 
showed that power input to the turbine 
was too high, and the burn-rate control 
valve was adjusted. However, on the 
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next missile flight, telemetry data in- 
dicated another turbine overspeed, and 
analysis showed that the system was 
operating at an even higher power output 
than in the first flight. Meanwhile, 
continuing ground tests of the HPU had 
uncovered other design deficiencies. To 
allow the flights to proceed in parallel 
with analyses, corrective actions, and 
tests, the ZEUS DM-15C pump was 
substituted on an interim basis. Cor- 
rective actions included: 


a. Addition of an orifice to the turbine 
exhaust duct to correct for the effects 
of low turbine exhaust pressures at 
high altitude 


b. A change to the pump design to incor- 
porate features, clearances, and 
’ gurface finishes used successfully in 
the DM-15C, initial SPARTAN, and 
DC-7 pump configurations. 


Improper operations of the gas generator 
led to these modifications: 


a. The grain design was changed to con- 
trol progressivity (increase of burning 
area and pressure with time) and to 
eliminate a short pressure dip that 
occurred during two other missile 
flights. After a sequence of analyses 
and tests of unsuccessful modifications 
had been completed, it was found that 
wrapping the grain with added thick- 
nesses of polyisoprene insulation 
solved the progressivity problem. 


b. A molybdenum screen was substituted 
for the stainless steel screen in the 
gas generator exit port. The stainless 
steel screen burned through during a 
ground test and a piece lodged in the 
burn-rate control valve causing a 
transient pressure increase. 


c. Design changes and procedural modi- 
fications precluded inadvertent shut- 
tling of the hot gas shut-off valve 
during factory inspection. Several 
potential solutions were tested before 
a successful one was found. 


The following bearing and gearbox prob- 
blems were encountered: 


a. During one flight, turbine speed sud- 
denly dropped. The drop was sub- 
sequently attributed to failure of a 
turbine bearing because the overlap 
mode of the gas generator was applying 
excessive loads to the turbine wheel. 
The turbine exhaust and the abort line _ 
were modified. ou 


b. A power drive train apparently failed 
during one flight, and overspeeding of 
the turbine wheel caused it to disinte- 
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grate. Extensive redesign provided 
new bearings, higher preload bearing 
pressure, positive turbine shaft lock- 
up, heat treatment changes for the 
gears, and an increased volume of 
lubricating oil. In addition, acoustical 
signature tests were implemented. 


5. A large oscillation of the accumulator 
regulating valve on one flight was attri- 
buted to a stiction-friction problem 
within the valve. The valve gain was 
reduced and small design modifications 
corrected the condition. A pressure 
drop with increasing hydraulic fluid 
temperature was attributed to the 
accumulator relief valve. Tighter 
manufacturing controls and a thermal 
shock test for flight qualification cor- 
rected this problem. 

In summary, the hydraulic system evolved 
from the hybrid configuration used in the early 
R&D flights through a series of component 
changes to an integrated design that functioned 
extremely well during the last half of the flight 


test program. 


Launch Cell Protective Cover 


Two cell covers, each weighing 9600 pounds, 
protect the SPARTAN launch cell and exhaust 
duct. Each cover is divided into halves which 
are designed to explosively separate in less 
than 0.5 second during the launch sequence. 
Reaction time was tested at the McDonnell- 
Douglas, Santa Monica facility and later during 
live missile firings at Meck. During the Santa 
Monica tests, which simulated an environment 
of snow and ice, excessive condensation on the 
underside of the covers affected the explosive 
separation of the cover halves. To prevent 
condensation, insulation was applied to the 
underside of the cover. 34.35 


Also, after a cell cover was opened by ex- 
plosive separation?® during a SPARTAN launch 
at Meck Island, an investigation showed that 
the lips of the base frame were either broken 
or cracked and that lip strength was only half 
that required. Loads on the lip during the 
decelerating phase of the cover-opening cycle 
were reduced by adding two new bolts on each 


cell cover half and modifying the decelerators 
(shock absorbers). 


These changes were verified by a ground 
test and an environmental test (snow and ice) 
at the SAFEGUARD site in North Dakota. The 
reaction times between the cell cover initiation 
signal and the signal for cover fully open and 
locked averaged 0.35 second during the envi- 
ronmental test. 


FLIGHT TEST PROGRAM 


A comprehensive flight test program demon- 
strated that the SPARTAN subsystem would 
meet its performance requirements and func- 
tion as an element of SAFEGUARD.?’ The 
program included the launch of extensively 
instrumented development missiles at Kwa- 
jalein. These were followed by system tests 
using SPARTANs launched from Meck Island as 
shown in Figure 10-9. 


Kwajalein Development Tests 


The primary requirements placed on the de- 
velopment flight tests were to develop, verify, 
and document the performance of individual 
missile subsystems and their ability to function 
as an integrated missile in the overall weapon 
system.33 Fifteen missiles were used during 
this test phase. Because many test objectives 
were independent of missile trajectory, data on 
each round were obtained by appropriate in- 
strumentation. Flight test planning of individual 
rounds was based on trajectory-dependent test 
objectives, which tested aerodynamics, thermo- 
dynamics (two-stage operation), flight control 
system operation (two-stage operation), third- 
stage operation, guidance communication, and 
warhead adaption kit operation. 


To provide the data needed for these objec- 
tives, sevéral trajectories and flight environ- 
ments were used in the Kwajalein tests: 


e Short, medium, and long (tangent) 
range 
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Figure 10-9. SPARTAN Missile in Flight 


e Low, medium, and high altitude 


e Low, medium, and high dynamic 
pressure 


e Early, medium, and late third-stage 
ignition. 

The test program was highly successful. The 
problems uncovered generated design improve- 
ments that were flight-tested in later develop- 
ment rounds®’ and contributed greatly to the 
success of the system tests. The test objec- 
tives, mission test plans, and flight test results 
for the Kwajalein development rounds have been 
documented in detail.” 


aa) 
ut 





Pasty 


prs 


7A 
a 


proce 


f 





Meck System Tests 


Twenty R&D SPARTAN missiles were launched 
from Meck Island during the SAFEGUARD Sys- 
tem test program,” followed by firing of five 
production missiles under the Product Assurance 
Verification Test (PAVT) program. The Meck 
test program demonstrated SAFEGUARD's 
ability to launch and guide SPARTAN missiles 
to intercept a live or simulated reentry vehicle. 
The intercepts were well within required miss 
distances. SPARTAN's compatibility with the 
rest of the SAFEGUARD System was verified, 
and additional data were gathered to evaluate 
the missile subsystem's performance, including 
performance in the more stressful regions of 
the field of fire. Reports on flight-test objec- 
tives, field-of-fire data, and flight-test results, 
including reliability and availability, for the 
Meck program have been prepared.'@4! 
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Summary 


Significant accomplishments in the Meck 
flight test program were successful performance 
of a launch cell protective cover, salvo-launch 
capability, and successful intercepts of live 
reentry vehicles. Complete interchangeability 
of missile sections was demonstrated during 
the test program. Both the Kwajalein Island 
and Meck Island flight tests showed that all 
important missile performance characteristics 
were significantly better than those specified 
before the development program started. 

The in-flight reliability of the last 30 missiles 
and the missile availability both exceeded 

the extremely high objectives set at the begin- 
ning of the R&D program.'243 
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SAFEGUARD radars and missiles are directed 
and controlled by programs executed on the Data 
Processing System (DPS).! The primary function 
of the DPS is to perform all calculations neces- 
sary to identify and track the threat, to allocate 
and determine the point at which the threat can be 
intercepted, and to generate orders necessary to 
launch and guide defensive missiles to the inter- 
cept point. The Command and Control Display 
Subsystem (CCDS) of the DPS provides the inter- 
face between man and the system for nuclear 
weapons release, monitoring of automatic opera- 
tion, and manual control, if required. Other 
major DPS interfaces include the Perimeter 
Acquisition Radar (PAR) or Missile Site Radar 
(MSR), the missile launch area (MSR only), and 
the data communications links to other 
SAFEGUARD sites, A Maintenance and Diag- 
nostic Subsystem (M&DSS) locates and corrects 
trouble; a Recording Subsystem (RSS) monitors 
the system; and a System Readiness Verification 
(SRV) Subsystem exercises and evaluates the 
system. 


The DPS was developed in two steps, DPS-1 
and DPS-2. In 1963, Bell Laboratories, with 
UNIVAC as a major subcontractor, began devel- 
oping DPS-1 for NIKE-X. A prototype system 
was operating at Whippany in 1967. A second 
system was later installed on Meck Island. At 
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Chapter 11. 


DATA PROCESSING SYSTEM 


that time, development of DPS-2 was started to 
meet the requirements of the SENTINEL deploy- 
ment, with the initial prototype checkout at 
Whippany targeted to begin in 1970. Bell Labo- 
ratories was the primary design agency, with 
Lockheed Electronics as a major subcontractor 
for memories and UNIVAC for design of the proc- 
essor. DPS-2 was not a new design but rather a 
major modification? of DPS-1 to improve the 
ease and economy of manufacture and test, and to 
achieve higher operational reliability, increased 
throughput, and ease of maintenance. To achieve 
these ends, design improvements were concen- 
trated in the following areas: 

e Addition of the M&DSS, providing a pro- 

grammable maintenance, diagnostic, and 


operation interface with the digital hard- 
ware via an automatic data bus 


e Provision of a flexible DPS partitioned- 
system capability with complete hardware 
independence 


e Simplification of input-output and peripheral 
device programming via hardware 
modifications 


e Standardization of DPS-2 interfaces 


@ Use of 500-nanosecond core memory for both 
program and variable store (DPS-1 used 
200-nanosecond coupled-film memory in 
addition to 500-nanosecond memory) 


e Improvements in basic digital hardware, 
such as connectors, cold plates, etc. 


e Use of beam-leaded Integrated Circuit 
Packages (ICPs) 


e Use of a multiple disc-drive (disc pack) 
file bulk-memory system 


e Development of tactical Cathode- Raye Tune 
(CRT) consoles, 

The first configuration of DPS-2 was installed 
and successfully checked out at Whippany begin- 
ning in 1970. Installation and checkout of a sec- 
ond system began at the Tactical Software Con- 
trol Site (TSCS) in Madison the following year. 


SUBSYSTEM DESCRIPTION 


Figure 11-1 shows the relationship of the DPS 
to other elements of aSAFEGUARD site. The 
heart of the system is the Central Logic and Con- 
trol (CLC), a multiprocessor, high-speed digital 
computer complex that interfaces directly with 
the radar and the CCDS. In addition to the CCDS, 
peripheral devices include the Exercise Control 
Unit (ECU), which is a part of the System Readi- 
ness Verification (SRV) Subsystem; the Data 
Transmission Controller (DTC); the M&DSS; the 
RSS; the Remote Launch Equipment (RLE); and 
the Logic-to-Relay Converter (LRC). The RLE 
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Figure 11-1, Data Processing System 


and LRC are used only with the MSR. A brief 
description of each major component follows. 


Central Logic and Control (CLC) 


The CLC executes the programs that direct 
the operation of a SAFEGUARD site. Itisa 
modular, multiprocessor system that performs 
all data processing and logical operations in the 
DPS in real time.’ Multiprocessing permits as 
many as ten Digital Data Processors to simulta- 
neously execute separate tasks or distinct parts 
of the same task. Multiprocessing also allows a 
number of unrelated programs to be processed 
at one time, thereby reducing any work backlog. 


Its modular design enables the CLC to meet 
the requirements of a particular site, and per- 
mits it to be partitioned* into two separate and 
independent computer systems‘ when required 
either for system exercises or for maintenance 


*Partitioning of the CLC into two distinct sys- 


tems is discussed under Sysiem Readiness 
Verification. 





operations. These two systems are designated 
"ereen" and "amber." 


Figure 11-2 shows a block diagram of the 
é CLC, which consists of: 


e Digital Computer Group 
a. Digital Data Processor Units (PUs) 
b. Program Stores (PSs) 
c. Variable Stores (VSs) 

: d. Input-Output Controllers (IOCs) 

4 e. Timing and Status (T&S) 


e Precision Frequency and Time Generator 
(PF&TG) 


e CLC Monitor (CM) (only used in TSCS). 


Three basic equipment configurations meet 
the specific data processing needs of the three 
SAFEGUARD sites. Supporting the MSR is a 
10-12-15-2-2 system consisting of 10 PUs, 

i 12 PSs, 15 VSs, 2 IOCs, and 2 T&S racks. The 
PAR requires a 5-7-14-2-2 configuration, and a 
1-3-3-1-1 configuration is used in the Ballistic 
Missile Defense Center (BMDC). There also is 
one PF&TG with each configuration. The CLC 
Monitor is used only in TSCS and is not a part of 
a tactical site. Interconnection between racks is 

' through interface switching units built into each 
rack. To achieve nearly continuous operation as 
economically as possible, the CLC employs 
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‘n+1" redundancy.’ Each of the five types of 
elements has a single replacement that is not re- 
quired for running the application software and is 
therefore redundant. For example, if the appli- 
cation software requires 12 racks of program 
store for execution, then at least 13 are provided. 
The '"n+1" element can be switched in to replace 
a failed element. 


The SAFEGUARD hardware concept permits 
fabrication of the DPS from a standard stock of 
racks, chassis, and integrated circuit packages. 
The design is based on integrated circuit technol- 
ogy using a modified direct-coupled transistor 
logic circuit having circuit delays in the 5- to 6- 
nanosecond range.* The hardware provides a 
flexible system for interconnecting groups of 
integrated circuit packages on chassis, and 
chassis into racks as shown in Figure 11-3. 
Wire-wrapping the integrated circuit package 
connections on the chassis enhances their relia- 
bility. Each chassis accommodates 275 inte- 
grated circuit packages, which represent more 
than 600 logic circuits. As shown in Figure 11-4, 
the chassis are housed in the water-cooled rack 
with two chassis mounted side by side on a chas- 
sis carrier plate that locates, supports, and 
cools the chassis. The chassis carrier plates 
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Figure 11-2, Central Logic and Control 
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Figure 11-3, SAFEGUARD Digital Racks 
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Figure 11-4. Construction Details of SAFEGUARD 


Digital Rack 


are mounted at a 1-inch vertical pitch within the 
rack, There is a maximum of 59 levels in the 
rack housing 118 chassis. 


The CLC required more access connections 
to the chassis than could be provided with rear 
access only. Therefore, both sides of the chas- 
sis are used for additional access terminals, 


. The rear contacts to the chassis are made in a 
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conventional plug-in manner. On the side, a 
linear-actuated cam arrangement engages the 
contacts after the chassis is properly positioned 
in the rack. Thus, wiring fields exist on three 
sides of the rack. In addition, internal connec- 
tions are provided at the interface between chas- 
sis, The chassis are side by side on the carrier 
plate to provide near-neighbor connections be- 
tween groups of chassis, In total, the rack has 
more than 40,000 possible signal connections. 
Since each rack has wiring on three sides, the 
racks must be arranged in a diamond pattern to 
allow physical access to all four sides of a rack. 
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Rack-to-rack interconnections are provided by 
plug-in coaxial terminal fields at the top of the 
rack, which allows as many as 11,520 connections. 


To preserve the integrity of high-speed pulse 
transmission between the various units of the 
multiprocessor, a characteristic impedance of 
100 ohms is maintained for the transmission of 
all signals. Coaxial cables are used for all con- 
nections between racks and for all rack-wiring 
runs longer than 5 feet. Twisted pair wiring pre- 
dominates in the rack. The chassis connector 
maintains a fixed impedance across the connec- 
tion by providing both a signal and a ground path 
using a highly reliable double-contact arrange- 
ment to enter a chassis. 


The memory racks include a 16K by 68-bit- 
per-word core memory unit and the associated 
interface logic switching circuits, which provide 
interconnection to the multiple units. The core 
memory units are air-cooled. They operate at a 
cycle time of 500 nanoseconds and have an access 
time of 300 nanoseconds, 


Digital Computer Group 


Digital Data Processor Unit (PU).7° The PU 
performs all arithmetic and logical operations 
for the CLC. As apart of a multiprocessor sys- 
tem, each processor operates asynchronously 
with respect to the memories, Input-Output Con- 
troller (IOC), and other processors. The proc- 
essor is divided into five sections: Program 
Control Unit (PCU),” Arithmetic Control Unit 
(ACU), Operand Control Unit (OCU)," Program 
Interface Switching Unit (Program-ISU), and 
Operand Interface Switching Unit (Operand-ISU). 
The five sections operate in parallel, with mini- 
mum control between sections. The main function 
of the PCU is to fetch instructions from Program 
Store and distribute them to the ACU and OCU. 
The ACU performs the arithmetic and logic oper- 
ations, The main function of the OCU is to fetch 
and store operands for the ACU. The ISUs pro- 
vide the communication links for the processor, 
the memories, and IOC. 


Program Store (PS).4% The PS accommo- 
dates the executive program and the assigned 
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programs used in the CLC. These programs are 
instruction words temporarily held in PS for sub- 
sequent transfer (fetching) to a requesting unit. 
The Store Transfer Unit (STU) in the T&S rack 
can store or fetch programs on request; however, 
the PU can only fetch programs. Therefore, 
loading and revising the contents of the PS must 
be performed via the STU. Each PS is divided 
into two independent, identical halves (A and B) 
each comprising an 8K memory and an \1su+*5 

A processor can have interleaved access to the 
two halves within a PS. This reduces the effect 
of queuing. Interleaving involves arranging the 
address structure of a program so that adjacent 
words reside in the independent halves of the 
memory. The 8K memory is a ferrite-core, 
magnetic memory system having a storage ca- 
pacity of 8192 68-bit words. 


Variable Store (VS).""* The VS stores op- 
erand data that is modified from time to time by 
the PU and provides temporary storage for pro- 
grams. The IOC and the PU OCU can store or 
fetch data and can also store programs; however, 
only the PU PCU can fetch these programs. 
Transfer requests can be for the left half of the 
word (byte 1), for the right half (byte 2), or for 
the entire 68 bits (both bytes). Each VS is com- 
posed of a 16K ferrite-core, magnetic memory 
and an ISU."-” Memory word length is 68 bits. 


Input-Output Data Controller (IOC)."" The 
IOC is a special-purpose computer that relieves 
the PUs of the time-consuming input-output oper- 
ations, The PUs operate much faster than their 
peripheral devices and therefore would be slowed 
down or tied up if required to execute I/O instruc- 
tions. Since the CLC is a multiprocessor sys- 
tem, the PUs would be competing with each other 
for access to peripheral devices, creating queu- 
ing problems if IOCs were not used; therefore, 
the IOC controls the flow of information between 
variable storage and the peripheral devices. 
Each peripheral device is connected to the IOC 
via one of 16 available channels. 


Timing and Status (T&S) Rack."* The T&S 
rack has three essentially autonomous units that 


perform four main functions in the CLC. The 
Timing Generator (TG)® provides real-time syn- 
chronization, The STU provides the means for 
writing data into PS. The Status Unit (SU) pro- 
vides a means to assemble and evaluate system 
status information and to partition the DPS. The 
control of these units is provided through the 
Interface Transfer Unit (ITU), Interface Switching 
Units (ISUs),5"* and the Channel Control Unit 
(CCU). 


Precision Frequency and Time Generator (PF&TG)27 


The PF&TG provides precision frequencies 
and a time-of-day output for the DPS. It contains 
an oscillator that generates a 5-megahertz base 
frequency. This base frequency is multiplied and 
divided to produce the wide range of precision 
frequencies required by various units in the DPS. 
Time-of-day outputs are generated and distributed 
to synchronize events with real time, An external 
frequency standard is used to calibrate the 5- 
megahertz oscillator. The equipment is housed 
in an air-cooled rack. In case of power failure, 
a battery rack supplies emergency power to the 
5-megahertz oscillator. 


Central Logic and Contro! Monitor (CM) 


This unit is not a part of the tactical system 
but was designed and built for TSCS to aid the 
initial hardware-software checkout. It checks 
and records certain operations of the CLC for use 
in such areas as debugging, performance tuning, 
and performance projection studies. For exam- 
ple, it can provide a trace of the last 1000 tasks 
executed before DPS recovery was initialized, a 
history of Nuclear Employment Authority (NEA) 
and Hostile Identification Enable (HIE) Status Unit 
bit use, and a history of PU, PS, VS, and IOC 
utilization. It gathers information by direct 
hardwired signals and by a request-acknowledge 
routine with the requesting unit. The CM handles 
requests with accompanying data and address bits 
in their order of priority. 


Recording Subsystem (RSS)” 


The RSS (Figure 11-5) provides the facilities 
for recording, storage, playback, and readout of 


DPS data and programs, The major functions of 
the RSS are to support installation of DPS equip- 
ment, support test exercises, and record data to 
provide a history of operation and maintenance 
events, In addition, the disc storage holds the 
program semi-permanently for system recovery. 


As Figure 11-5 shows, the RSS operates with 
two identical sets of peripheral equipment, This 
permits it to be divided into two independent sys- 
tems and thereby provides full recording capability 
for both DPS subgroups when the DPS operates in 
a partitioned condition at the PAR or MSR. 


The major components of the RSS include a 
digital rack called the Recording Set Controller 
(RSC) and the following commercially- 
manufactured peripheral equipment: magnetic 
tape transports, multiple hardened disc drive 
units, punched card readers, and computer out- 
put printers, Bidirectional data transfers be- 
tween the peripheral devices of the RSS and the 
CLC are via the RSC on a request-acknowledge 
basis. 


Interface Subsystems 


The SAFEGUARD System requires three inter- 
face subsystems to implement local and remote 
missile launch functions and intersite communi- 
cations. Two of these, the Logic-to-Relay Con- 
verter and the Remote Launch Equipment, are 
used only with the MSR configuration to provide 
an interface between the CLC and the local and 
remote missile launch facilities, respectively. 
The other subsystem, the Data Transmission 
Controller, is used with the BMDC, MSR, and 
PAR configurations to provide a communications 
interface. 


Logic-to-Relay Converter (LRC)30,31 


The LRC provides the necessary pre-launch 
communication and conversion link between the 
logic circuitry of the Input-Output Controller 


(IOC) in the DPS and the relay circuitry of the 
Launch Preparation Equipment (LPE) in the col- 


located missile field at the MSR. This link pro- 
vides for the software-controlled launching of 
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Figure 11-5. Recording Subsystem 


SPRINT and SPARTAN missiles. The communi- 
cation link between the DPS and the LRC is re- 
dundant throughout. The two LRCs used are 
functionally identical and interface with separate 
IOCs, but only one can be maintained on-line at 
a given time. The LRC is made up of the follow- 
ing units: 


e The Missile Launch Equipment Controller 
(MLEC) which receives orders from the 
IOC in the form of 34-bit data words and 
interprets and forwards the data words, 
as logic levels, to the Missile Launch 
Equipment Adapter. 


e The Missile Launch Equipment Adapter 
(MLEA) which converts the logic-level 
signals to relay control voltages, which 
constitute the missile orders that are 
transmitted to the LPE. Missile status 
signals, in the form of relay control volt- 
ages, are returned to the MLEA from the 
LPE,.. The MLEA converts the missile 
status signals to logic levels that are trans- 
ferred back to the MLEC, where they are 
encoded into data words for transmission 
to the IOC, 
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e The Power Supply Set which supplies the dc 
voltages to operate the logic circuitry in 
the MLEC. 


Remote Launch Equipment (RLE) 


This interface is covered in Chapter 9, which 
describes the SPRINT Missile Subsystem. 


Data Transmission Controller Group (OTCG)32,33 


The DTCG permits wideband and voiceband 
digital communication links between MSR and 
PAR configurations and between sites in the 
SAFEGUARD System. The DTCG has redundant 
equipment for partitioning purposes. It consists 
of: (1) Data Transmission Controllers, (2) Data 
Transmission Controller Adapters, (3) crypto- 
graphic equipment, and (4) data sets with asso- 
ciated data set adapters. The government 
furnishes the cryptographic equipment and data 
sets. 


Maintenance and Diagnostic Subsystem 
(M&DSS)*-37 

The M&DSS (Figure 11-6) provides a central 
facility for SAFEGUARD digital equipment main- 
tenance. Only units allocated to the amber sys- 
tem are so maintained. The M&DSS contains the 
hardware and software necessary to perform or 
aid in: 7 
DPS initialization 
DPS recovery and loading 
Hardware fault detection and location 


Visual display of individual] digital equip- 
ment status, including allocation (green or 
amber partition and test enabled/isolated) 
and summary error information 


Remote control and monitoring of dc power. 


The M&DSS has two distinct facilities for run- 
ning diagnostics. The primary one uses the M&D 
Processor (MDP) Group to execute diagnostic 
tests in a fully automatic, high-speed manner, 
with automatic interpretation of results; the 
other uses the M&D Console Group as a back-up 
for manually aided execution and interpretation 
of certain diagnostic tests. Each test facility is 
. linked via logic in the M&D Data Controller and 
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special hardwired data paths to all the digital 
racks in the DPS and to certain digital racks in 
the radar areas. Using these data paths, M&DSS 
software can access each rack as required for 
DPS initialization, recovery, and diagnostic . 
operations, 


The diagnostic tests are executed on equipment 
placed off-line in the amber system. Monitoring 
of equipment in the green system is restricted to 
checking for correct output patterns. 


System Readiness Verification (SRV) 
Subsystem 

The primary objective of the SRV subsystem 
is to verify the tactical readiness of the aA 
SAFEGUARD System, including its hardware, Ey 
software, andpersonnel. To accomplish this, 
the CLC is partitioned into two independent sys- 
tems (green and amber), and a combination of 
system tests and system exercises is performed. 
These assess site readiness by determining the 
availability and reliability of system hardware, 
the performance characteristics and functional 
capabilities of system hardware and software, 
and the proficiency of operating personnel, 
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Figure 11-6. M&D Subsystem 
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particularly in the Command and Control Display 
Subsystem (CCDS). Before these tests and ex- 
ercises can be performed, the personnel must 
identify the elements to be verified, describe the 
processes (hardware, software, and procedures) 
involved, and state the expected results. 


The SRV subsystem contains the following 
elements: - 
e Exercise Data Processor (utilizing the 
amber partition of the CLC) 
Exercise Control Unit (a part of the DPS) 


Radar Return Generator (a part of the 
radar) 


e System Exercise Console (a part of the 
CCDS). 

Together, these elements form the exercise 
system in the amber partition of the DPS. Ina 
system exercise, they drive the tactical system 
in the green partition of the DPS, causing the 
tactical system to respond as it would in a real 
engagement and thereby allowing evaluation of 
the dynamic system response and readiness. 


The only part of the SRV subsystem in the DPS 
that has not been described is the Exercise Con- 
trol Unit (ECU). This is a digital rack that pro- 
vides the interface between the exercise system 
and the tactical system. It supplies the data and 
control paths necessary to: (1) monitor radar 
orders from the tactical system for the Exercise 
Data Processor (EDP) and inject simulated target 
information from the EDP into the tactical system 
via the Radar Return Generator, (2) monitor mis- 
sile orders from the tactical system for the EDP 
and return simulated missile responses from the 
EDP to the tactical system, and (3) furnish com- 
munications between the exercise and tactical 
systems and/or between sites, It also interrupts 
all command paths to the missile launch stations 
to provide an extra measure of safety during sys- 
tem exercises. 


Command and Control Display Subsystem 
(CCDS) 3-2 _ 

The CCDS facilitates monitoring and directing 
the tactical operation and maintenance of the 
SAFEGUARD System. 
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The CCDS is composed of command and con- 
trol equipments manned by personnel trained to 
perform tactical and maintenance operations, 
Tactical operations cover the weapon system 
response to the potential or actual threat to the 
protected area, Surveillance, target detection, 
target identification, and engagement activities 
are part of the tactical phase of operations in the 
CCDS area. Maintenance operations are con- 
cerned with maintaining each element in the 
SAFEGUARD System at its maximum availability 
by monitoring and coordinating maintenance for 
each subsystem, 


Major operating equipment (Figure 11-7) used 
in the CCDS are: 


e Logic Control Buffer — provides the inter- 
face with the CLC and the M&DSS 


e Buffer Store — provides buffering to com- 
pensate for the difference between the data 
rates of the CLC and those required by the 
displays 


e CRT Consoles — provide a dynamic inter- 
face between the human operators and the 
equipment (Figure 11-8 shows a typical 
CRT console) 


e Console Logic Support Units (CLSUs) — in- 
clude the circuitry required to generate the 
CRT console displays 


e Non-CRT Consoles — provide operators 
with status information and controls to vary 
functions. With the exception of an end 
plate, they are electrically and mechan- 
ically identical to the Control Indicator 
Units associated with the CRT Consoles 


e System Status Display Boards — provide 
status information on major elements of 
the SAFEGUARD System 


e System Status Display Support Unit 
(SSDSU) ~— includes the circuitry required 
to generate the signals which drive the 
System Status Display Boards 


e Teletypewriters (TTYs) — furnish commu- 
nications between operating personnel and 
the CLC, 


Other major operating equipments in the CCDS 
are: 


e Nuclear Employment Authority (NEA) 
Equipment — consists of two Guided Missile 
Launch Enable Controllers (GMLECs) and a 
Guided Missile Launch Enable Group (or 
NEA rack) in the Combat Operations Center 
at Cheyenne Mountain and one NEA rack at 
the Missile Direction Center (MDC) in 
Grand Forks (see Figure 12-3 in Chapter 12) 
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Figure 11-7, Command and Control Display Subsystem — Console, 
Wall Display, and Teletypewriter Interface 


e Launch Enable Equipment (Figure 11-9) — 
consists of two Launch Enable Message 
Controllers (LEMCs) and one Launch 
Enable Message Transmitter (LEMT) in the 
Ballistic Missile Defense Center, and a 
Launch Enable Message Receiver (LEMR) 
with a Launch Enable Transmission Set 
(LETS) at the collocated missile farm and 
each of the remote missile farms. 


The GMLECs control a coded message gener- 
ator to release or withdraw authority to expend 
SPRINT and SPARTAN missiles. The generator 
can also produce a test message to check the 
major parts of the NEA system. The NEA rack 
at the MDC decodes the message and presents 
status independently to hardware (wall displays 
and Missile Monitor Test Console) and through 
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the status unit to the tactical software, which 
drives the CRT displays. Redundancy is used 
when required in the NEA system design to 
assure reliability. Considerable fault indication 
and fault isolation circuitry also is included.34 


The LEMCs control a coded message genera- 
tor in the LEMT, which provides either an enable 
message or a disenable message to the Launch 
Enable system. A test message also can be gen- 
erated for system checkout. The LEMT provides 
status signals to the DPS and LRC to indicate 
which message is being transmitted. The coded 
message is received by the LEMR, checked for 
errors, and slowed down for transmission 
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Figure 11-8. Typical CRT Console with Control Indicator Unit 
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through the LETS to the electromechanical Launch 
Enable Coded Switch (LECS) in each missile cell. 
The LECS has functional contacts, which inter- 
rupt the High Energy Firing Unit charge and trig- 
ger circuits and one of the Launch Order signals 
when the system is in the disenabled or safe con- 
dition. When in the enabled position, these paths 
are completed. The LECS also has a status mon- 
itor contact that indicates to the LEMR which 
state resides in the switch. These status signals 
are summed and fed back to the DPS and LRC. 


The LECSs are electrically recodable from the 
LEMR by the Launch Enable Recode Test Set. 
Redundancy is used where required in the Launch 
Enable design to assure a high degree of relia- 
bility. Considerable fault indication and fault 
isolation circuitry also is included,®“ 


COMPARISON OF PERFORMANCE 
OBJECTIVES AND RESULTS 

One of the primary reasons for developing 
a parallel, modular computing system for 
SAFEGUARD is the potential for high perform- 
ance. Besides having high availability, a multi- 
processor organization possesses a great deal of 
reserve power, which, when applied to a problem 
with the appropriate degree of parallelism, can 
yield high performance, This type of problem is 
associated with a radar tracking system and must 
be solved in real time. 


In a multiprocessor system, the processors 
gain access to main storage according to a pri- 
ority rule. The rate at which each processor 
executes instruction depends, therefore, on the 
severity of this queuing at main storage. 
Throughput is defined as the number of instruc- 
tions of a particular instruction mix executed per 
second by n processors. 


Adequate performance or throughput of a par- 
allel processing system depends on several hard-~ 
ware factors, which include the speed of the proc- 
essor; the speed of program store, including its 
priority circuit; the total number of processors 
relative to the total number of independently 


addressable program stores; and the number of 
instructions executed per memory word fetched. 
From a software viewpoint, the distribution of 
programs and data sets within the modular mem- 
ory and the instruction mix of the particular pro- 
grams in execution also are important factors, 
which directly affect throughput. 


Since variable store queuing, in general, is 
less than that at program store, its effect has 
been eliminated in the throughput data presented 
here. This has been done by dedicating a sepa- 
rate variable store rack to each processor for 
experimental studies. 


Throughput data has been gathered using 
multiprocessor hardware with as many as ten 
processors. Benchmark programs, which pro- 
vide varying instruction mixes, have been used. 
Four instruction mixes were selected for testing. 
The NOP mix, consisting of no-operation in- 
structions, defines an upper bound on through- 
put. The LOGICAL mix is a representative mix 
similar to CLC operating system code that might 
be executed during real-time operations. The 
MATH mix is also a representative mix, since 
it is a portion of the cosine subroutine from the 
CLC operating system. The JUMP mix consists 
exclusively of jumps and represents a kind of 
lower bound on throughput. 


Figure 11-10 shows the effect of requiring all 
processors to execute from one program store. 
The number of instructions executed per second 
increases with the number of processors until 
the program store is returning instructions as 
fast as it can. Throughput levels off when this 
point is reached, and a further increase in the 
number of processors does not increase through- 
put. 


Figure 11-11 shows the effect of providing an 
equal number of processors and program stores. 
For this case, the number of processors and 
program stores is incrementally increased from 
one to ten. The program stores are not dedicated 
to a processor on a one-for-one basis, but their 
access by the processors is randomized such 
that several processors may be attempting to 


11-12 





22 3 


SCALE FOR LOGICAL 
LIMITS v4 
20 +1 MIPS 


MILLIONS OF INSTRUCTIONS PER SECOND (MIPS) 
MILLIONS OF INSTRUCTIONS PER SECOND (MIPS) 


FoRSIL NEY 


cane 


pri 





pe 
te 
i 








0 1 2 3 4 5 6 7 8 9 10 
NUMBER OF PROCESSORS 


Figure 11-10. N Processors Executing from One 
Program Store 


read from the same program store at once. 


number of processors. Data is shown for the 
LOGICAL and MATH mixes only. 


Figure 11-11 shows an even distribution of 
memory access over all program stores. To 
determine what happens to throughput for an un- 
equal workload distribution, a series of runs were 
made for both the LOGICAL and MATH mixes 
where the number of processors was kept equal 
to the number of program stores with one impor- 
tant difference; one of the program stores was 
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Figure 11-11. N Processors Executing from N 
Program Stores 


equally. Figures 11-12 and 11-13 show the re- 


Hence, some reduction in throughput due to sults for the six to ten processor cases. The 

queuing is expected. The effect of queuing is curves represent throughput as a function of the 
e small for one to ten processors; Figure 11-11 "favored" program store. Zero percent means 
t : shows that throughput increases linearly with the ten processors are executing out of nine program 


stores. Note that throughput is highest when the 
"favored" program store shares equally in the 
workload. 


The curves of Figures 11-12 and 11-13 show 
the sensitivity of throughput to an equal distribu- 
tion of the workload in memory. For instance, if 
one considers a 10-percent reduction in through- 
put to be serious, the above curves show for the 
seven-processor case that a single program 
store can have almost 40 percent of the workload 


3 selected as a "favored" program store and its 

B fraction of total instructions executed was varied 
from 0 to 100 percent while the remaining pro- 

ne gram stores shared the remaining workload 


without a serious reduction in throughput. For 
the ten-processor case, the corresponding num- 
ber is approximately 25 percent. Therefore, 
as long as the workload is not too unequally 
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Figure 11-12. Unequal PS Loading, LOGICAL Mix 


distributed, the dependence of throughput on work- 
load distribution should not be critical. Through- 
put dependence on more than one program store's 
having more than an equal share of the workload 
has not been investigated. 


MAJOR CHALLENGES AND INNOVATIONS 


The following major technical innovations 
were made during the development of the DPS. 


A Multiprocessor, Partitionable System with 
(n+1) Redundancy 

The CLC represents the first practical appli- 
cation of the multiprocessing concept to a large- 
scale computing system. In this modular de- 
sign, as many as 10 processors and 2 Input/ 
Output Controllers share as many as 32 memory 


N=10 PROCESSORS 


22 


MILLIONS OF INSTRUCTIONS PER SECOND (MIPS) 





0 10 20 30 40 50 60 70 80 90 100 
% INSTRUCTIONS EXECUTED FROM FAVORED PS 


Figure 11-13. Unequal PS Loading, MATH Mix 


racks, The units are interconnected by a flexible 
switching network that facilitates partitioning 

the system into two independent computers. 
Partitioning can be controlled by software, and 
complete reconfiguration can be accomplished 

in less than 1 second. 


Although it may have been possible to design 
a single processor with adequate performance, 
the CLC is a.multiprocessor machine for three 
reasons. First, a single processor sufficiently 
powerful would have been a complex machine, 
difficult to design, and difficult to get working. 
Second, a single-processor system would not 
have been expandable; if a more powerful ma- 
chine were later needed and none were available, 
major software changes would have been re- 
quired. Also, multiple processors satisfy a 
wide range of processing requirements, 
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including smaller applications. Finally, the 
multiprocessor design increases availability be- 
cause processing can continue even if some 
processors have failed. 


The processor is the most important element 
in establishing the real-time computing capacity 
of the CLC, so the design of a high-speed 
processor was a primary goal. Each processor 
contains three control units that operate asyn- 
chronously with respect to each other. Timing 
within each control unit is overlapped to some 
degree so that more than one instruction can be 
in execution. The use of high-speed arithmetic 
algorithms and associated logical implementation 
has been exploited advantageously to increase the 
flow of operands through the arithmetic sections. 
The resulting processor design can execute 
successive fixed-point add operations on full- 
word 32-bit operands at an average rate of 4. 15 
million per second. Results with more than one 
processor are given in Comparison of Per- 
formance Objectives and Results. 


A multiprocessor design hinges on its storage 
design. A number of possible strategies are 


‘available to handle the necessary references of 


the multiple processors to main storage. The 
first strategy used in the design is the splitting 
of main storage into two independent portions, 
called program (or instruction) store and vari- 
able (or operand) store. 


To further increase the data flow rate between 
processors and main storage, program and vari- 
able store are further subdivided into modular 
groupings. Variable store is organized as 16 in- 
dependent racks, with an independent data path 
from each rack to each of the processors. Since 
queuing is heavier at program store than at 
variable store, program store is organized as 
32 independent modules with an independent data 
path from each module to each of the processors. 
Processor addressing is interleaved between two 
modules; that is, the address structure is ar- 
ranged so that adjacent program store words re- 
side in two separate modules. 
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The memory module cycle time of 500 nano- 
seconds and the double-word size of 64 bits pro- 
vide a memory bandwidth greater than that re- 
quired for maximum performance of a single 
processor, Each program store and variable 
store rack holds 16,384 64-bit words. There 
are four parity bits associated with each mem- 
ory word, 


The CLC can be partitioned into two inde- 
pendently operating computers, each capable of 
executing its own job stream. By convention, 
these two partitions are called. green and amber, 
with green usually designating the larger of the 
two fractions. However, since the computer is 
composed of a number of modular elements, the 
boundary between green and amber is almost 
completely flexible. In fact, all elements can be 
brought into the green partition to operate as a 
very large multiprocessor computer with as 
many as ten processors sharing the job load. 

As a further degree of flexibility, some elements 
(such as memory elements) may be placed 

into a shared green/amber state, in which they 
are available to both partitions simultaneously. 
Finally, an element may be defined as neither 
green nor amber but isolated. This state is 
necessary to remove malfunctioning elements 
without shutting down the entire system. 


It is even more significant that parti- 
tioning is under program control, Further, the 
control logic for effecting partitioning is re- 
dundant. A fundamental asymmetry allows the 
green partition to have priority over the amber 
partition, The partitioning logic may be placed 
into a state whereby a master/slave relation- 
ship exists between the green and amber parti- 
tions. Control software residing on the green 
partition may alter the partitioning of the system 
at any time. The amber or slave partition can 
in no way alter the partition boundaries. 


Early fault-tolerant systems employed 100- 
percent redundancy through use of a complete 
standby system; that is, the system required to 
support the full workload was duplicated, with 


data processing proceeding in parallel on each 
system, This organization is conceptually sim- 
ple and, upon detection of a failure in either 
system, the other system can carry on the data 
processing workload. 


The multiunit system approach to high per- 
formance can provide high system availability 
without the need for costly, complete duplication. 
The "n+1" redundancy approach has reduced the 
amount of equipment added for redundance and 
for system exercise to a fraction of that required 
for a complete standby system. 


A Versatile and Workable M&D Approach 


The SAFEGUARD System's specific tactical 
mission is extremely brief compared to the life 
of the system. Once a tactical mission has be- 
gun, the M&DSS ceases fault isolation and re- 
pair; if serious failure occurs, system recovery 
must automatically execute, using its built-in 
redundancy. Therefore, the fault detection and 
isolation features of the M&DSS are directed 
toward maximizing system availability, which 
- is the probability that, at any point in time, a 
complete set of fault-free DPS resources exists 
for a mission. 


The M&DSS contributes to maximizing system 
availability in two ways. First, M&D tests are 
periodically run on critical DPS equipment to 
supplement real-time fault detection methods in 
minimizing the mean-time-to-awareness of 
hardware faults. These tests are automatically 
scheduled by real-time software in the green 
partition and the test requests are sent to the 
M&DSS over a special interface through the SU. 
In this way, every processor in the DPS is 
switched into the amber partition and tested once 
every hour; the complete amber partition is tes- 
ted once each hour; and the green IOC with its 
slaved peripheral controllers is switched 
amber and tested once every four hours. The 
M&DSS passes test results back to green system 
software again via the SU interface. 
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Second, and more important, the M&DSS min- 
imizes the mean-time-to-repair of faulty racks 
by rapidly identifying a minimum set of replace- 
able or easily repairable modules in which the 
fault is located. These fault isolation functions 
may be initiated in response to fault symptoms 
detected either in real time or during the non- 
real-time scheduled tests described above. In 
either case, fault isolation takes place with the 
failed rack isolated from the rest of the DPS. 


The M&DSS accomplishes this goal through 
the unique integration of two significant mainte- 
nance concepts. First, it uses a special two- 
way maintenance data path into each DPS digital 
unit which bypasses normal data paths. Second, 
it uses a small general-purpose computer, dedi- 
cated to system testing, to apply tests over the 
maintenance paths and interpret test results. 


The communication interface between the 
green partition SU and the M&DSS provide a 
rapid and flexible means for bringing mainte- 
nance resources to bear on any DPS fault indica- 
tion. Nonetheless, until a specific faulty rack 
has been identified, the particular response to 
be made to any given fault indication often in- 
volves judgements based on the total status of DPS 
resources. Thus, normal SAFEGUARD main- 
tenance operations involve a significant degree 
of manual interaction. In general, two primary 
maintenance management functions are perfor- 
med manually: 

1. Monitoring and response to overall sys- 
tem status as reported by green system 
real-time software and hardware dis- 
plays 

2. Direct control of maintenance testing; 
the M&DSS will not honor any scheduled 
test request unless manual "permission" 
is granted, any test in progress may be 
manually aborted, and alternate tests 
may be requested via green system soft- 
ware and the SU interface. 

Experience has demonstrated the fundamental 
power and flexibility inherent in the primary 
M&DSS feature, the extensive maintenance data 
interface with the entire DPS, in concert with 
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the general-purpose computing capability of the 
M&D Processor. Just as encouraging, however, 
has been the performance of a set of extended 
M&DSS capabilities developed during the early 
phases of installation and operation, before the 
widespread availability of M&D tests. 


Central to the extended capabilities of the 
M&DSS are the Digital Unit Exerciser (DUXs). 
One such program exists for each DPS rack type. 
Each DUX program facilitates controlling func- 
tional operations of a rack on a macroscopic 
level and "dumping" the contents of individual 
registers or groups of related registers within 
the rack. In actual hardware operation, DUXs 
have been used primarily to provide manual in- 
teraction, via the M&DSS, with a set of real-time 
programs originally developed to verify the com- 
plete functional capabilities of the DPS. Data 
currently being gathered at SAFEGUARD sites 
show that this mode of fault detection and isola- 
tion is still important. The various DUX capa- 
bilities also have provided an extremely power- 
ful means of aiding system software debugging by 
allowing dumps and snapshots of otherwise in- 
accessible DPS registers without perturbing the 
very condition being probed. This capability has 
been used extensively throughout the SAFEGUARD 
software development. 


A Processor Unit with a Basic Operate Time 
of 200 nsec 


When the NIKE-X development began, operate 
speeds in this range were in advance of the state 
of the art. A demonstration of a prototype unit 
operating at this speed was conducted success- 
fully at UNIVAC in 1965, and the first full-scale 
model was successfully operated in 1967. 
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A Coupled Film Memory with a 68-bit Word 
Length and 200-nsec Cycle Time 


Memory speeds in this range were specified 
initially to match the processor design speed. 
During the early days of NIKE-X, laboratory 
models and small memories had achieved this 
speed, but the challenge of mass-producing 


_large, fast memories remained. This challenge 


was met, and 200-nanosecond coupled film 
memories were manufactured successfully for 
the Whippany and the Meck Installations. 
A System Readiness Verification Subsystem 
for Realistic Simulation without Relying on 
Processor Self-Checking 

Experience with the Analog Tactical Environ- 
ment Simulator in the Meck system and a 1968 
study resulted in the exercise concept for 
SAFEGUARD. This concept uses the amber sys- 
tem CLC working through the ECU interface to 
drive the green system CLC or the Missile Sub- 
system in a simulation mode, and working through 
the Radar Return Generator to inject targets into 
the receiver to check system operation in its 
entirety. This concept permits the green sys- 
tem software to remain virtually unmodified in 
the exercise mode, The approach has been pro- 
ven successful in system operation to date. 


A Quick-Reaction, Remote-Controlled Nuclear 
Safety System 


Previous Army nuclear safety systems re- 
lied on close proximity of the weapon to the of- 
ficers responsible for weapon release. In addi- 
tion, the time required to release SAFEGUARD 
had to be shorter than any previous system 
reviewed by the Nuclear Weapon System Safety 
Committee. The Launch Enable system, as 
designed, provides safety and remote release 
capability. 
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Chapter 12. 


BALLISTIC MISSILE DEFENSE CENTER 


The Ballistic Missile Defense Center (BMDC) 
is the highest echelon of command and control in 
the SAFEGUARD System. The Commander-in- 
Chief of the Continental Air Defense Command 
(CINCONAD) exercises operational command 
through the BMDC. The BMDC, in turn, directs 
the activities of the Perimeter Acquisition Radar 
and the Missile Direction Center, and controls 


_the launch and burst of nuclear missiles. BMDC 


facilities are collocated with the CINCONAD 
Combat Operations Center (COC) in the Cheyenne 
Mountain Complex of the North American Air 
Defense Command (NORAD). 


ROLE 


The BMDC provides a single-point interface 
for the Commanding General of the U.S. Army 
SAFEGUARD Command, whose forces staff the 
SAFEGUARD System, and CINCONAD, who is 
charged with the defense of the continental United 
States against air attack. After receipt of 
presidential authority to release nuclear weapons, 
the CINCONAD COC authorizes using the 
SAFEGUARD System's stockpile of nuclear 
missiles by entry of the Nuclear Employment 
Authority (NEA) at the COC. The BMDC, by 
consolidation and retransmission, provides the 
COC with the information nec essary to support 
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the authorization. (See Figure 12-1 for an 
overview of the SAFEGUARD.command 
hierarchy.) 


The BMDC also supports the SAFEGUARD 
System's mission by processing and consoli- 
dating early warning data on detections made by 
non~SAFEGUARD sensors, e.g., data the 
SAFEGUARD System needs to respond to sub- 
marine-launched ballistic missiles. 


The COC/BMDC interface provides the 
SAFEGUARD System with alert and readiness- 
level coordination with other defense systems 
as well as coordination with the Strategic 
Offensive Missile Forces of the Strategic Air 
Command. The BMDC sends SAFEGUARD- 
generated early-warning, attack-assessment, 
and satellite-observation data to the COC. 


DEVELOPMENT SCHEDULE 


SAFEGUARD System Command authorized 
development of the BMDC Subsystem in April 
1970, 


Analyzing the hardware support required for 
the subsystem's development revealed that the 
Tactical Software Control Site at Madison, New 
Jersey, might not be suitable. Arrangements 
therefore were made for early delivery of the 
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tactical hardware to Guilford Center, North 
Carolina. This hardware, eventually destined 
for Cheyenne Mountain, was in Guilford Center 
ready for use by the software developers in 
September 1972. It was named the Early 
Ballistic Missile Defense Center (EBMDC). 


The system development consisted essentially 
of three versions of the Weapons Process: 
BW1.0, BW1.1, and BW1.2. 


The initial version, BW1.0, was released in 
December 1972, and contained the necessary 
interfaces and responses to satisfy the four-site 
deployment. 


The second version, BW1.1, was released in 
June 1973. It was developed from information 
for a single-site deployment and contained cor- 
rections which were revealed by the test program 
for BW1.0. The EBMDC was removed from 
Guilford Center in August 1973, and in January 
1974 was ready for use in Cheyenne Mountain. 


In February 1974, BW1.2 was installed. This 
version included all features known to satisfy the 


‘requirements of single-site deployment. How- 
.ever, as a result of the functional and system 


test program, new Tactical Load Modules were 
periodically created until, on August 15, 1974, 
a final version of BW1.2 was released. This 
version was tested and turned over to the Army 
on October 1, 1974,- thereby completing develop- 
ment of the BMDC. 


DESCRIPTION 


The BMDC contains a minimal, nonredundant 
processor using standard SAFEGUARD hardware. 
This processor primarily performs command, 
control, and display functions. 


Hardware 


The hardware consists of a Central Logic and 
Control, a Recording Subsystem, a Command 
and Control Display Subsystem, a Data Trans- 
mission Controller Subsystem, and a Mainte- 
nance and Diagnostic Subsystem. 
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Central Logic and Control (CLC) 


The CLC used is the minimum configuration 
capable of supporting the BMDC mission. A non- 
redundant CLC is justified at the BMDC since it 
does not control radars or in-flight defensive mis- 
siles, The site mission can allow a significantly 
reduced Availability/Reliability Product without 
materially affecting the overall SAFEGUARD 
defense capability. In view of this reduced re- 
quirement, the standard SAFEGUARD hardware 
was considered sufficiently reliable, 


The CLC for the BMDC consists of one Dig- 
ital Data Processor Unit, three Program Store 
Units, three Variable Store Units, one Input/ 
Output Controller, and one Timing and Status 
Unit. This is a '1-3-3-1-1" configuration. 


Recording Subsystem (RSS) 


The RSS used in the BMDC includes only 
those components required to support BMDC 
operations. These components are four disk 
memory units, four magnetic tape transports, 
two computer output printers, and one punched- 
card reader. 


Command and Control! Display Subsystem (CCDS) 


The CCDS associated with the BMDC includes 
man/machine interface facilities to allow ra- 
tional, manual control of the BMDC and the sys- 
tem as a whole. The major elements of the 
CCDS are briefly described in the following 
paragraphs. 


BMDC Commander's CRT Console. The 
BMDC Commander's CRT Console enables the 
Commander to exercise manual control ac- 
tions — such as Hostile Identification Enable, 
SPARTAN Hold Fire, and Nuclear Enable In- 
hibit — over the SAFEGUARD System. 


In addition, the BMDC Commander may in- 
voke Hold Fire, Cease Engage, and Force Inter- 
cept on individual targets. The associated CRT 
display provides the information needed to per- 
form these manual actions. 


Command and Control Consoles. The CCDS 
also includes three general-purpose Command 


and Control Consoles. These consoles provide 
operating positions for the BMDC Tactical Direc- 
tor, Assistant Tactical Director, and System 
Capability Officer. At each console, any of the 
roles can be assumed without degrading manual 
capability. The console position normally manned 
by the Tactical Director does not include a tele- 
typewriter, while those positions normally 
manned by the Assistant Tactical Director and 
the System Capability Officer do have teletype- 
writers. Figure 12-2 shows the three Command 
and Control. Consoles as installed in the BMDC 
Operations Room. 


Through his console position, the Tactical 
Director may exercise control over the entire 
SAFEGUARD System as well as control over the 
launch and burst of individual missiles. This 
degree of control is provided by manual actions, 


such as System Defense Mode Control, Missile 
Allocation Control, Hostile Identification, Hold 
Fire, and Cease Engage. The associated CRT- 
display provides the information needed to per- 
form these manual actions. 


The Assistant Tactical Director's console 
allows this officer to support the Tactical Direc- 
tor. The teletypewriter at the Assistant Tactical 
Director's position allows manual entry of cer- 
tain tactical messages normally received from 
the CINCONAD COC via the data link, thereby 
providing an alternate route for these messages. 


The System Capability Officer's console 
informs that officer about BMDC hardware and 
software. In addition, the position permits the 
officer to restructure the BMDC Weapons Process 
to make optimum use of available resources as 
the tactical environment changes. 





Figure 12-2. BMDC Operations Room with the System Capability Officer (left}, Tactical Director (foreground), 
Assistant Tactical Director (right rear}, and System Status Display Unit {rear} 

















The System Capability Officer receives 
enough data about the SAFEGUARD System as a 
whole to allow him to advise the BMDC Com- 
mander and Tactical Director about the system's 
capability. From this data, he also may coordi- 
nate maintenance for the entire system. The 
teletypewriter at this console position enables 
the System Capability Officér to inform the 
COC about the BMDC. 


System Exercise Console. The System Exer- 
cise Console is used by the BMDC Exercise 
Director to manually control and monitor a 
single-site or multisite exercise. 


In addition to the CRT console, the BMDC 
Exercise Director's position includes a tele- 
typewriter so that he can manually modify the 
simulated system posture as well as the posture 
included in the system exercise. 


Data Management Console. The Data Manage- 
ment Console allows manual monitoring of the 
data links connecting the BMDC with appropriate 
components of the overall system. 


This non~CRT console permits intersite 


.time synchronization of the BMDC Weapons 


Process with the interfacing SAFEGUARD Sys- 
tem sites. In addition, the Data Management 
Console permits testing of the Data Transmis- 
sion Controller, the Data Transmission Con- 
troller Adapter, and the connecting data links. 
This console position also includes a teletype- 
writer, which can be used to enter parameters 
and receive status reports from the Data Proc- 
essing System (DPS) concerning the intersite 
data links. 


Data Processing Console. The Data Proc- 
essing Console permits the Data Processing 
Officer to manually control the subsystem's 
hardware and software. 


In addition to the facilities provided by the 
CRT console, the Data Processing Officer's 
normal position includes two teletypewriters. 
These machines allow the officer to enter 
parameters and receive status reports about the 
subsystem's hardware and software. One of the 
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teletypewriters is in an active mode and the 
other is in a standby mode. 


Guided Missile Launch Enable Group. (See 
Figure 12-3.) The Guided Missile Launch En- 
able Group (also known as the NEA rack) is 
peripheral to the BMDC through the Command 
and Control Display Subsystem. The Guided 
Missile Launch Enable Group is in the CINCONAD 
COC. Two Guided Missile Launch Enable Con- 
trollers (GMLECs), also located in the COC, 
are used to release the NEA message. By vir- 
tue of the interface parameters, the Guided 
Missile Launch Enable Group appears to the 
Command and Control Display Subsystem as 
a special-purpose teletypewriter. 


The signals generated when the Guided Mis- 
sile Launch Enable Group is manually activated 
are related to the authorization by the National 
Command Authority to employ nuclear weapons. 
These signals require special handling by the 
BMDC Weapons Process. The NEA data is 
identified by the unique entry point in the hard~ 
ware. 


System Status Display Units. The System 
Status Display Units (Wall Status Panels) and 
Site Readiness Level Signs, with the associated 
System Status Display Support Unit, display data 
about the site and system status, National De- 
fense Posture, and readiness and alert levels. 
The System Status Display Unit in the BMDC 
Operations Room (Figure 12-2) is a secondary 
display because most of its information is 
available on other display media, such as the 
CRT consoles. 


The Site Readiness Level Signs and System 
Status Display Units in the Maintenance Control 
Center are more important. They are the pri- 
mary source of information concerning alert 
and readiness status for personnel manning 
the center. The System Status Display Unit 
in the Operations Room is monitored by the 
COC through closed-circuit television as a 
major source of data about the SAFEGUARD 
System. This is an interim arrangement pend- 
ing completion of the data link between the COC 
and the BMDC. 
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Figure 12-3. Nuclear Employment Authority Interface 


Data Transmission Controller Subsystem 


The Data Transmission Controller associated 
with the BMDC includes the appropriate logic 
modules to support an interface with three data 
channels. The data rate in the BMDC Data 
Transmission Controller is set at 4800 bits per 
second. 


The SAFEGUARD System requires a data- 
link connection to the NORAD Communications 
Processor, which in turn provides a data inter- 
face with the CINCONAD COC and the Space 
Computational Center, both collocated with the 
BMDC in the Cheyenne Mountain Complex. 


A data link from Cheyenne Mountain 
(Colorado) to Grand Forks Air Force Base 
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(North Dakota) connects the BMDC to the 
remainder of the SAFEGUARD System (see 
Figure 12-1). 


Maintenance and Diagnostic Subsystem (M&DSS) 


The M&DSS at the BMDC includes mainte- 
nance~related equipment for computation, 
auxiliary input/output operations, and auxiliary 
information retrieval. It also provides the man/ 
machine hardware interface to implement or 
support certain CLC loading and initialization 
operations, certain DPS recovery operations, 
and certain hardware fault isolation procedures. 


Software 


The BMDC software consists of a basic tac- 
tical software package (the BW1 Process), the 
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Tactical Operating System, a Basic Operating 
System, the CLC Control Facility, and appropri- 
ate M&D software. 


The following paragraphs describe these 
software components, setting forth their unique 
characteristics and their interrelationships. 


BMDC Weapons Process : 


The BMDC Weapons Process (BW1) meets the 
standards imposed by the DPS performance re- 
quirements. * 


The BW1 is designed to create a software 
process that can adequately control error condi- 
tions and to provide a structure that can be 
efficiently maintained. Since the BW1 employs 
a single processor, the design must permit the 
system exercise function to co-exist with the 
weapons process in the DPS, yet it must be 
invisible to the tactical portion of the process. 


To attain these goals, the BW1 was parti- 
tioned into five functional areas. These are the 
Process Coordination Major Functional Area, 
the BW-Operations Major Functional Area, the 
Displays and Controls Major Functional Area, 


‘the Intersite Communications Major Functional 


Area, and the System Exercise Major Functional 
Area. The following paragraphs present an 
overview of each Major Functional Area. 


Process Coordination. This area is responsi- 
ble for management and surveillance of the BW1 
during tactical or system exercise, real-time 
operation, initialization, and termination. 


BW1 programming tests for errors in the 
data base and in execution. The normalized 
cumulative error levels can be displayed to the 
BMDC System Capability Officer as an indica- 
tion of subsystem sanity. Also, the Process 
Coordination Task and the Working Interface 
Table Request Processor Tasks provide the 
request and responses necessary to establish 
and terminate a system exercise. 





*See reference number 40 in References for 
Chapter 4. 
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BW-Operations. This area is divided into 
eight tasks: the Operational Mode Determina- 
tion Task, the Visible Threat Consolidation 
Task, the Defense Status Consolidation Task, 
the Alert and Readiness Level Dissemination 
Task, the Nuclear Weapons Control Task, the 
Special Acquisition and Track Assignment Task, 
the Defense Mode Determination Task, and the 
NEA Transmission Task. The first seven of 
these tasks are cyclically enabled. When they 
execute, they determine if there are messages 
or manual actions to be processed. 


The NEA Transmission Task is unique in its 
method of enablement. This task is enabled 
whenever the coded NEA messages are pre- 
sented to the specially designated teletypewriter 
port of the Logic Control Buffer in the CCDS 
hardware (see Figure 12-3). 


Displays and Controls. This area provides 
the software to drive consoles, displays, and 
teletypewriters of the Command and Control 
Display Subsystem. Because of the magnetic- 
core-size limitations for the BMDC Weapons 
Process, the Displays and Controls Major 
Functional Area uses disk-to-Variable-Store 
overlay extensively. 


Intersite Communications. This area de- 
tects and validates messages from netted sites; 
it also formats messages to netted sites. In 
addition, this functional area monitors and 
evaluates communication links and maintains 
intersite time information. Manual access 
to the Intersite Communications Major Function- 
al Areais provided by the Data Management 
Console. Upon successful completion of a DPS 
recovery, this area initiates the intersite mes- 
sages necessary to update the BWi data base. 


System Exercise. This area supports both 
local and multisite system exercises for the 
BMDC, while remaining invisible to the 
tactical portion of the BMDC Weapons Process. 
In addition to certain control operations, such 


as initiation, termination, error recovery, and 
displays, the System Exercise Major Functional 
Area can simulate the tactical data interfaces 
with the Missile Direction Center and/or the 
NORAD Communications Processor (Combat 
Operations Center/Space Computational Center). 
Simulation of the Missile Direction Center im- 
plies simulation of the Perimeter Acquisition 
Radar. In any exercise mode, this functional 
area simulates all sites which interface with the 
BMDC but which are not participating in the 
exercise. 


Tactical Operating System (TOS) 


The TOS controls the real-time execution of 
SAFEGUARD DPS programs. This controt 
involves sequencing programs, transferring 
data between storage and the peripheral devices, 
detecting errors and recovering from them, 
assigning available hardware as required, 
periodically testing DPS equipment, managing 
the CCDS and RSS, and providing communica- 
tions and logic for controlling the operating 
system. 


Basic Operating System (BOS) 


The BOS provides a debugging environment 
for tactical software integration on the CLC. 
It allows single-processor, non-real-time 
execution on the CLC and facilitates manual 
interaction for patching, dumping, testing, 
and disc maintenance. Although the tactical 
software will function without BOS, the system 
provides essential tools. 


CLC Control Facility 


The CLC Control Facility provides the basic 
configuration, control, and loading functions 
required to do the following: to initially load 
the CLC and to reconfigure and recover the 
DPS, to partially or completely load the CLC, 
and to reinitialize the data base. Additionally, 
the CLC Control Facility provides such utility 
functions as a mathematics package, number 
conversion routines, time-of-day formatting, 
device allocation, device status management, 
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a software interface with the CLC Status Unit, 
and string manipulation. 


Maintenance and Diagnostic Software 


The M&D software consists of a combined 
executive/utility system, which is resident in 
the M&D Processor; development programs 
that are used to build and debug all M&D 
Processor software; and user-oriented pro- 
grams for hardware maintenance. 


COMPARISON OF PERFORMANCE 
OBJECTIVES AND RESULTS 

The BMDC subsystem delivered to the govern- 
ment on October 1, 1974, fully meets all per- 
formance objectives as delineated in the various 
design control documents. 


Performance Measurement 


Four tests measured the capability of the 
subsystem to meet the performance objectives: 
the Unit Test Sequence, the Progression Test 
Sequence, the System (End-Point) Test Se- 
quence, and the Netted System Test Sequence. 


Unit Test Sequence 


The Unit Test Sequence verified that the 
performance of each distinct software module 
of the Weapons Process could meet the require- 
ments imposed by the Functional Design 
Specification. : 


Progression Test Sequence 


The Progression Test Sequence verified 
that each newly released Tactical Load Module 
could meet the performance requirements im- 
posed by the design control documentation. 
The Progression Test Sequence measured the 
performance of the subsystem for given tasks, 
e.g., Visible Threat Consolidation, Defense 
Status Consolidation, etc. fons 
System Test Sequence , 


The System Test Sequence verified the func- 
tional capability of the complete subsystem 
Tactical Load Module operating under a stress 
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or load condition. Subsystem response was 
derived from intersite messages and visual 
indications available through the display 
media in the subsystem, 


Netted System Test Sequence 


The Netted System Test Sequence is part of 
the System Integration and Evaluation Test Plan, 
which supports the overall SAFEGUARD Sys- 
tem performance evaluation. The Netted Sys- 
tem Test Sequence is a series of tests which 
evaluate the performance of the system in nor- 
mal peacetime as well as in simulated attack 
conditions. 


Performance Measurement Analysis 


The data yielded by the four test sequences 
helped to validate the subsystem performance. 
The raw collected data was processed off-line 
using the SAFEGUARD Data Reduction System. 
The performance of the subsystem as evidenced 
by the reduced data was then compared to the 
performance objectives. Correlation between 
the reduced data and the predicted performance 
was considered to be evidence of attaining the 
performance objective in question. 


By using this criterion, the subsystem was 
judged to meet all performance objectives im- 


posed by the design control documentation. 
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Part ill. 


MANAGEMENT AND OVERALL APPROACH 


To summarize the lessons learned from ABM 
R&D is challenging, because the period of time 
was long, the breadth of research wide, and the 
follow-on development program immense. This 
part of the report discusses the most impor- 
tant lessons learned about the management and 
overall approaches used in a project such as 
this. The discussion is discursive and makes 


no attempt to present detailed supporting data 


or arguments. Every member of Bell Labora- 
tories Divisions 65 and 66 management contri- 
buted to this report by suggesting items, writing 
portions, and/or criticizing early drafts. There 
is a reasonable consensus on the views ex- 
pressed here, but probably not on their relative 
importance. 


Because this was a very big project, parti- 
cularly the SAFEGUARD portion, the lessons 
are most directly applicable to other very large 
projects and many will probably also apply to 
smaller programs, There has been no effort to 
analyze the effect of project size or to modify 
the conclusions for different conditions. 


Under the prime contract with Western 
Electric, Bell Laboratories had overall re- 
sponsibility for essentially all R&D work. Since 
Bell Laboratories has its own special organiza- 
tional characteristics, many of the statements 
made here have probably been affected by those 
characteristics. There has been no attempt to 


determine just how these characteristics have 
affected the conclusions or how the conclusions 
might be modified by different organizations. 
However, the close relationship between Bell 
Laboratories and Western Electric was exploited 
continuously during development and production. 


| OVERVIEW 


Feasibility 


Perhaps the most important lesson of this 
experience, and particularly of the SAFEGUARD 
part, is that development of a large weapons 
system can be completed on schedule to pre- 
scribed performance specifications, with effec- 
tively controlled costs. It is true that changes 
during development drastically cut down the 
overall deployment. Also, the overall system 
design was modified because of changes in ob- 
jectives and because of test results obtained 
during development. However, the development, 
including integration of the first installed site, 
proceeded on schedule and the system met the 
prescribed performance specifications. Cost 
performance is harder to determine because of 
inflation during the period, deployment changes, 
and lack of a design-to-cost objective. But it 
seems clear that costs were controlled effec- 
tively. 


Given the experience with some other im- 
portant weapons system developments (most of 
them smaller or less complex than this one) in 
failing to meet schedules, performance spe- 
cifications, or cost objectives, the ABM R&D 
effort is valuable as an example that such de- 
velopments can be successful, This is particu- 
larly important because one major argument 
against developing SAFEGUARD was that it 
could not be done successfully. 


Overall Approach 


One principle followed during the entire re- 
search and development period was to continu- 
ously evolve the system concept; that is, to re- 


peatedly synthesize and analyze systems that met | 


prescribed objectives against prescribed threats. 
Although most of the effort was spent on re- 
search and development of specific subsystems 
(radars, missiles, data processors, etc.), 
there were continuous studies of how subsys- 
tems could be used within a system. The sen- 
sitivity of system performance to subsystem 
specifications and to changes in objectives and 
threat was repeatedly studied. Designers con- 
centrated on aspects of subsystem performance 
most important to overall system performance. 


The overall approach might be summarized 
as plan, simulate, test — plan, simulate, 
test — plan, simulate, test. Every part of the 
development benefited from detailed planning. 
While there was little or no attempt to specify 
a planning format or technique, every subpro- 
ject manager was strongly encouraged to plan 
in detail the design, implementation, and test- 
ing of his piece of the system, Although these 
plans had to be revised many times, it was very 
beneficial to have them. To keep track of prog- 
ress, several methods of reporting were tried, 
as discussed later. 


Simulations were used on all levels of detail 
and forall parts of the design. In every case, 
simulations more than paid for themselves in 
either improved performance or reduced cost. 


When trouble was found, it was also discovered 
that more or better simulation would have pre- 
vented, or at least reduced, the difficulties. Be- 
cause the simulation results were important, 
there were extensive efforts to validate them with 
data from real tests. 


Perhaps the most important part of the over- 
all approach was testing. Effective testing de- 
pends strongly on detailed test specifications. 
Most of the development time and cost went into 
testing, and it always happened that even more 
tests were possible and, in fact, desirable. Con- 
sequently, test planning almost always consisted 
of selecting only the most essential tests from 
among those desirable. After each test, data 
analysis continued until any failures or anoma~ 
lies were understood. These comprehensive 
analyses, particularly of the Meck Island tests 
at Kwajalein Atoll, frequently resulted in signi- 
ficant system improvements. 


Constructing the prototype Missile Site Radar 
(MSR) at the Kwajalein test site made way for 
the Kwajalein field experiments, which were un- 
doubtedly the single most important step in 
achieving success. The project would have been 
even more successful if a more complete system 
prototype had been built. Building a prototype 
Perimeter Acquisition Radar (PAR) at a northern 
site early in the R&D program would have def- 
initely produced a better system design. There 
were major problems with developing the PAR 
software, mostly because no complete, con- 
sistent set of requirements could be checked out 
on a prototype PAR system. Without a prototype, 
the problems with requirements were not identi- 
fied clearly by the developers until the final de- 
velopment phase. No large project should be 
undertaken without allowing time and resources 
for constructing and extensively testing a com- 
plete prototype. 


The Kwajalein tests are perhaps better termed 
"field experiments, '' and they were almost un- 
believably successful. Successful tests meant 
not just meeting normal test objectives; they 
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produced data invaluable for completing system 
design. For instance, the data obtained on tank 
breakup were vital to the success of the project. 
Experiments were carried out in a carefully 
controlled environment (which helped both the 


. conduct and analyses of tests) rather than in the 


design threat environment only. It would have 
been impossible to obtain data for the final de- 
sign if the tests had only been trials against 
the design threat. 


In many other projects, separate organiza-~ 
tions within a company carry out their own field 
operations. A principal reason for the success- 
ful ABM field test program was the rotational 
assignment of systems, hardware, and software 
designers to the field sites. The reward was 
not only the transfer of design intent to the 
field tests but also the experience fed back to 
the design work when the designers returned to 
their laboratories. 


Probably second in importance only to the 
Kwajalein tests were the tests at the Tactical 
Software Control Site (TSCS) in Madison, N. J. 


Not only were these tests vital to software de- 


velopment, they were also an important source 
of data on the hardware and helped validate the 
system simulations. Later sections of this 
discussion expand on the importance of testing 
and the TSCS. 


The one constant factor throughout the pro- 
ject was the inevitability of change. At no time 
were the objectives, threat, design, or deploy- 
ment completely stable, and it was unrealistic 
to assume that any of them would remain fixed. 
Therefore, it was vital to be prepared for 
changes and to have effective procedures for 
controlling them. Making changes in hardware 
was a familiar problem from Bell Laboratories' 
experience on Bell System and other military 
projects, and procedures for handling them 
were reasonably well established. But the 
complexity and high performance of the 
PAR and MSR_ systems necessarily pro- 
duced a greater number of changes during 
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testing and checkout than ever experienced be- 
fore with smaller systems of lesser performance. 


By careful planning, many changes were intro- 
duced into major subsystems — the MSR at 
Meck, the TSCS at Madison, the tactical 
MSR in North Dakota, and the PAR in North 
Dakota — during tests without materially af- 
fecting schedules. By scheduling test time among 
the many equipment users, changes could be 
introduced if the necessary drafting, shop, and 
quality assurance teams were available when re- 
quired. A mutual understanding between design- 
ers of hardware and designers of software test- _ 
ing routines, plus careful scheduling, normally _ 
allowed enough time to physically disrupt hard- 
ware to introduce a change. Changes necessarily 
must be designed in small packages, but large 
packages of changes could be introduced because 
they were scheduled for periods when the system 
was down for a day or more and because work- 
crew schedules were kept flexible. After the 
changes, enough time was allowed for regres- 
sion testing of areas affected by the changes. 


By keeping the main technology fixed during 
the program, it was possible to produce, on 
schedule, equipment with proven reliable de- 
signs. On many other projects, hardware de- 
signs are continually changed to keep abreast of 
changing technology, schedules continually slip, 
and hardware is unreliable. 


While controlling hardware design changes 
was a big problem, controlling system and soft- 
ware changes was even more difficult because 
procedures were not as well established. It 
took a great deal of effort to develop techniques 
for controlling such changes. These techniques, 
plus strict discipline, resulted in a control pro- 
cedure without which the software development 
would have failed. (See Chapter 4 of Part I 
for a discussion of lessons learned in control- 
ling software changes. ) 


Overall system requirements were specified 
early in the development, and formal procedures 
for controlling changes in these requirements 


were immediately instituted. Software design 
was tied closely to these controlled system re- 
quirements. Even though there were many, 
many changes, this procedure was crucial to 
successful software development. 


Organization 


. 


One of the most important characteristics of 
this project was the interface between Bell 
Laboratories and the Army agency responsible 
for ABM development. Relationships were 
open, -frank, and informal. Although formal 
contractual requirements were carefully nego- 
tiated and carried out, most of the information 
exchanges between the Army and the contractor 
were informal. Consequently, problems could 
be discussed as they came up and proper action 
taken immediately. Also, the significance of 
problems could be determined and the right 
priorities established. Little effort was wasted 
on insignificant problems. 


It was very important that the Army side of 
the interface be a single, responsible Program 
Manager. As with any very large project, there 
were many interfaces at various levels with the 
Army's SAFEGUARD organization both in Wash- 
ington and in Huntsville, Alabama. In addition, 
liaison was necessary with many Army organi- 
zations; e.g., nuclear effects, facilities re- 
quirements, communications. Despite the 
many interfaces, the SAFEGUARD System Of- 
fice and the SAFEGUARD System Command be- 
came an effective single agency responsible 
for resolving differences and adjudicating prob- 
lems whenever they occurred. 


Overall system changes were negotiated be- 
tween the System Requirements Department at 
Bell Laboratories and the corresponding or- 
ganization in the SAFEGUARD Project Office at 
Huntsville. Questions about system performance 
were discussed in proper context, and appro- 
priate formal action taken to change the system 
requirements, Subsystem development was 
thereby protected from many "what if" studies 
which could have delayed progress. 


This project, like others its size, took 
several companies to carry out, However, it 
was made clear that Bell Laboratories had over- 
all responsibility, and top managers in Bell 
Laboratories used their authority to make major 
decisions quickly. If responsibility had been 
split among several companies, or if other red 
tape had impeded Bell Laboratories managers, 
it is improbable that schedules could have been 
met and very probable that costs would have in- 
creased, Because Bell Laboratories could make 
decisions quickly, technical authority over sub- 
contractors could be delegated to lower levels 
when cost was not involved. This speeded up 
decision-making; it also increased motivation 
and inbred a sense of responsibility in the 
people working on the project. 


Interfaces between Bell Laboratories and the 
subcontractors received special attention. In 
very large and technically complex development 
projects, the importance of this cannot be 
overemphasized, Technical developments and 
problems in each area affect other areas. 
Whether the related developmental areas are 
within a single company or split among contrac- 
tor and subcontractor, almost continuous inter- 
change of information is essential. Monthly or 
quarterly technical reviews are inadequate un- 
less informal exchanges on the engineering level 
go on, by telephone and personal visits, at least 
once every week or two. With major subcon- 
tractors, it is often necessary to keep an en- 
gineering group at the subcontractor's plant. 
Without such frequent and informal engineer- 
ing level exchanges, the technical development 
would not have been as quick or successful as 
it was. 


In hardware subcontracting, enough time 
should be spent, before development starts, to 
work out a detailed design specification that both 
contractor and subcontractor fully understand. 
Requirements will change, so an early base for 
defining them is very important. This is par- 
ticularly true for a cost/schedule/performance 
incentive contract. 
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Attention to contractor/subcontractor re- 
lationships was particularly important with soft- 
ware development, Because it is impossible to 
state software requirements precisely until 
after system design is completed, it is very dif- 
ficult to employ subcontractors to develop com- 
plex software. If subcontractors are used, the 
interface must-be carefully specified and moni- 
tored. The large subcontractor effort used to 
develop SAFEGUARD software was divided into 
smaller, well-defined tasks that interfaced di- 
rectly with the Bell Laboratories first-line 
supervision, Tasks were rated monthly by the 
technical supervisor, and the rating results 
determined the final fee on the Cost-Plus-Award- 
Fee (CPAF) contract. This interface ensured 
responsive subcontractor performance at a man- 
ageable level on a very large project. These 
methods worked well, and when problems de- 
veloped it was usually where the customary in- 
terface procedures had not been used. 


Perhaps the most important principle fol- 
lowed in organizing the project was to install a 
top-quality manager over each subproject and 
give him full responsiblity for schedule, cost, 
and performance, The managers had broad and 
deep technical competence as well as managerial 
competence. Furthermore, they were expected 
to be aggressive in not just passively accepting 
a job definition and carrying it out. Instead, 
they actively explored interfaces between their 
subprojects and all others to anticipate problems. 
Although they used a variety of techniques to 
carry out their responsibilities, time after time 
their ability to recognize technical problems was 
fundamental in finding solutions to them. While 
it was certainly important to appoint the best 
general manager, it was absolutely vital that 
he have a high technical competence as well. 


SPECIFIC SUGGESTIONS 


This section contains comments less basic, 
but more specific, than those in the preceding 
sections. While the suggestions are grouped 


into general areas, each is largely independent 
of the others. 


Requirements 
System 


To design and develop a large, complex sys- 
tem in a few years, a large number of people is 
obviously required (several thousand at the peak 
for SAFEGUARD). To properly coordinate their 
efforts, a good set of requirements and/or spe- 
cifications is essential. For SAFEGUARD, the 
major specifications were: 

e Brief overall SAFEGUARD System speci- 

fications 


e Missile Site Equipment Subsystem speci- 
fication 


e Perimeter Acquisition Site Equipment Sub- 
system specification 


e SPARTAN Subsystem specification 
e SPRINT Subsystem specification 


e Communication Equipment Subsystem spe- 
cification 


e Ballistic Missile Defense Center specifi- 
cation 


e Data Processing System Performance Re- 

quirements (DPSPR). 

The DPSPRs controlled software implementa- 
tion and actually specified the detailed system 
requirements. The following comments are 
based on experience with all of the specifica- 
tions, but mostly with the DPSPRs. 


A decision about the level of detail and the 
completeness of requirements must be carefully 
weighed. The decision depends on the relation- 
ship between the organization preparing the re- 
quirements and the organization that implements 
them, the resources available, the time avail- 
able, and various psychological factors. Obvi- 
ously, the closer the organizational relationship, 
the less need for completeness. On the other 
hand, if the organizations belong to different 
companies, requirements must be complete and 
detailed, It is probably better to err on the side 
of too much detail rather than too little. On 
SAFEGUARD, too few resources (about 7 percent) 
were allocated to preparing the requirements. 


Designers naturally object to overly detailed re- 
quirements because it limits them, and this im- 
portant, legitimate criticism should be care- 
fully guarded against. However, problems re- 
sulting from lack of detail can be even more 
serious, and therefore must be guarded against 
even more carefully. 


It is vital that requirements be available as 
early in the program as possible. Those pre- — 
paring requirements must make decisions quick- 
ly, on the basis of incomplete analyses, and 
publish them in the shortest possible time. 

- Management should soften criticism of defects 
in the early issues of the requirements, because 
the defects inevitably result from pressure for 
early availability. 


Because objectives change, because problems 
become better understood, and because require- 
ments must be written quickly, changes are in- 
evitable. It is absolutely necessary to institute 
a way to control changes relatively early in the 
process. This change control must keep pro- 
posed changes from getting lost and ensure that 
every designer is working with a consistent and 
updated set of requirements. 


Requirements serve two purposes. They tell 
the customer what he is buying and the designer 
what he is designing. If these purposes conflict, 
the priority is to give the designer clear and 
unambiguous requirements. If necessary, give 
the customer explanatory material. 


To summarize: 


e Publish the first issue of requirements 
as early and as completely as possible. 
The first issue then forms a baseline 
for changes. 


Controlling changes in requirements is 
essential. The control system should 
become formal before the project is half 
completed. 


Carefully plan the degree of detail and 

completeness in the requirements. Do 

not allow unanalyzed resource restrictions 
-to determine these answers. 


Availability/ Reliability 


In a system like SAFEGUARD, a complete 
and easily understood availability and reliability 
budget is essential for each subsystem. This 
budget reflects the system effectiveness require- 
ments. In the real world of fixed resources and 
flexible system objectives, these requirements 
should be considered as objectives. As such, 
they should be reviewed carefully at intervals to 
ensure that the system stays in balance and that 
the cost of achieving the original objectives is 
clearly understood. In SAFEGUARD, for ex- 
ample, if system effectiveness is measured by 
the number of Minuteman ICBMs that survive an 
attack, a wide range in availability and reliability be 
will produce acceptable results. The original 
objectives were set for the SENTINEL Area 
Defense System, which required more stringent 
requirements than the Minuteman defense. More 
thorough consideration of possible reductions in 
objectives might have lowered some requirements 
for components and subsystems, 


Man-Machine Subsystem 


The requirements originally specified for the 
CRT console, the lightpen, the teletypewriter, 
and other units in the Command and Control Dis- 
play System (CCDS) were far more extensive 
than necessary to support the man-machine re- 
lationship. Furthermore, it was found later that 
to supply many of these special capabilities 
required a software effort greater than the 
project could support. The man-machine inter- 
face was therefore greatly modified, resulting 
in two out of three available lightpen modes not 
being used. In addition, many CRT console ca- 
pabilities, such as the A-scope mode and lower 
case letters, are unused throughout the CCDS. At 
the beginning, a hard-nosed and realistic examina- 
tion of what man really had to do to control an 
ABM system, plus the assurance that require- 
ments were compatible with the capability of 
supporting software, would have drastically re- 
duced requirements on the Command and Control — 
System. The equipment would have been more 
economical to design, produce, and maintain. 
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Similarly, the user directed that many en- 
gagement control actions be included in the re- 
quirements because they were useful in anti- 
aircraft systems, even though they were in- 
effective for ABM systems, These actions in- 
cluded Hold Fire, Force Intercept, and Com- 
mand Destruct. If the requirements for ABM 
control actions had been agreed on sooner, the 
costs of designing, developing, and integrating 
display and control software would have been 
lower. While these problems did not signifi- 
cantly reduce capability of the man-machine 
subsystem, they definitely reduced the quality 
and "elegance" of the design. 


‘Nuclear Surety and Safety 


There should have been earlier, more effec- 
tive communication among design organizations 
and the government agencies responsible for 
nuclear surety and safety: the National Security 
Agency (NSA) and the Nuclear Weapons System 
Safety Committee (NWSSC). Prompt liaison 
could have avoided misunderstandings, mis~ 
takes, and costly last-minute changes to the 
Nuclear Enable Authority and Launch Enable 


' systems. 


The agencies began intensive final reviews 
after designs, which incorporated changes 
suggested during their preliminary reviews, 
had been released for manufacture. Under these 
circumstances, designers were understandably 
reluctant to accept the agencies' comments and 
suggestions, After an additional year of review, 
NWSSC suggestions became a mandatory re- 
quirement for a new Launch Enable design con- 
cept. The designers regarded the new design 
and other practices imposed by the agencies as 
"ex post facto" requirements. Much cost, delay, 
and contention could have been avoided if: 

e@ All the organizations involved had better 

understood the roles of NSA and NWSSC 


and the strength of their requirements and 
recommendations 


e Before design work started, the agencies 
had documented their requirements, pre- 
ferred concepts, and standards developed 
and imposed on other projects (e.g., use 
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of nonsymmetrical connectors, omission 
of continuity loops, etc.) 


@ The above had been used as the basis for 
agency review with minimum application 
of criteria developed during review from 
"state of mind" guidelines 


e The reviews had been more in parallel with 
’ design, to supply incremental concurrences 
from design through field test, 


Intelligence Data 


Gathering intelligence through U. S. observa- 
tions of Soviet ICBM tests should have been much 
more responsive to the ABM development. The 
sensors on the U. S. instrumentation ships 
should have been modified so they could collect 
the required data. Instead, large sums were 
used for devising questionable frequency and radar 
cross-section scaling relationships, for extensive 
target modeling, and for costly simulations which 
could not always be validated. 


Vast quantities of intelligence data were col- 
lected. There was enough information on the 
composition and levels of Soviet forces, and an 
adequate design threat was eventually defined. 
However, data essential for design, develop- 
ment, and evaluation of critical target selection 
and tracking algorithms were lacking. They 
could have been obtained by observing Soviet op- 
erational tests. During the years 1967 through 
1972, data requirements were sent repeatedly to 
the Research, Development, Test and Evaluation 
(RDT&E) Directorate at Huntsville, who in turn, 
forwarded the requests to the intelligence agencies. 
With the advent of SENTINEL in 1967, UHFand S- 
band data were badly needed, yet UHF data re- 
mained scarce and incomplete andS-band data 
never were collected. 


Radar cross-section and trajectory data for 
supporting the ABM development were needed 
at the operating frequencies, polarizations, and 
resolutions of the MSR and PAR. There should 
have been a deliberate effort to collect data on 
RV wake characteristics at S-band, on tank 
breakup at S-band, and on all exoatmospheric 
objects at UHF. Wake and tank breakup data 
were collected later by the Meck MSR during 


live U.S. tests at Kwajalein, but these data were 
not totally adequate in the exoatmospheric regime. 


Hardware Design Implementation 
Hardware Design Release 


When SAFEGUARD was committed to veer 
duction, schedules were quickly established for 
releasing hardware designs for manufacture. 
These designs were developed during the R&D 
program, and had to be baselined and trans- 
ferred from the R&D contract to the production 
contract. Hardware could then be manufactured 
- according to production schedules, but subse- 
quent design changes had to be made under for- 
mal production control procedures. These pro- 
cedures proved to be cumbersome in making 
changes to R&D designs not yet stabilized for 
the production system. It would have been 
more cost effective to start manufacture with a 
less rigid configuration control program, and 
to control changes under somewhat less strin- 
gent procedures. Then, after a transition 
period to allow for design stabilization, formal 
production procedures could have been intro- 
duced. 


A related problem was the Critical Design 
Review (CDR) required before the design could 
be released to production. The CDR was in- 
tended to allow the Army and Bell Laboratories 
to assure themselves that the design met system 
requirements and was ready for release to pro-~ 
duction. Since the equipment components had 
different lead times and were ready for release 
at different times, CDRs were held at various 
levels, on hardware ranging from magnetic 
apparatus to power supplies to power racks to 
subsystems. The CDRs should have been held 
only for large, very important items such as 
the MSR receiver, while lesser items should 
have been released prior to a CDR if required 
by production schedules. Army engineers 
could have been kept informed of the design 
status through the same type of regular contact 
with the design engineers that existed in the 
development program. 


Design Drawing Reviews 


In normal practice, the drafting organization 
and the responsible engineer spot-check com- 
pleted drawings for accuracy and then release 
them for manufacture. If errors are detected 
later, the responsible engineer is notified and a 
change order for the correction is prepared. 


In SAFEGUARD, an outside contractor re- 
viewed selected drawings submitted for release 
to manufacture. The intent was to avoid subse- 
quent change orders by assuring that the draw- 
ings contained no errors. In the early submit- 
tals, which came from reputable subcontractors, 
many errors were detected. More often than not, 
the errors did not affect manufacturing the pro- 
duct. Instead, they involved incomplete compli- bs 


’ ance with various drawing practices and format 


requirements, 


The result was numerous drawing rejections 
and led to much effort being expended on addi- 
tional checks of drawings before they were 
released. Subcontractors completely checked 
all their drawings before releasing them. Then 
a prime contractor representative visited the 
subcontractor plant and conducted a further 
In spite of these repetitive reviews, 
drawing changes were still required when 
Shops used the drawings for procurement and : 
manufacture, because the shops found real 
problems associated with product manufacture. 

The expensive, time-consuming drawing 
quality audit, more often than not, uncovered 
only superficial problems. 


review. 


Drawing Designation 


An excessive number of drawings were gen- 
erated because of the initial requirement that 
each separate detail be on a different 11-million- 
numbered drawing, This volume of drawings is 
not required in commercial manufacture, nor is 
it used in the Bell System. It is expensive both taxi 


_ in dollars and in the time required for drafting. 


After much discussion of the cost of the pro- 
gram, the contracting agency gave some relief 
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by allowing contractors to include families of 
similar parts on a single drawing, with designa- 
tion of a particular item by dash number. Cer- 
tain drawing details were also permitted on top 
assembly drawings only when the detail did not 
have a separate requirement, e.g., aS a spare 
part. If this relief had been extended to all 
subassemblies and been present from the start, 
considerable expense could have been avoided. 


Organization of Work 
System Responsibility 


Major responsibility for SAFEGUARD was 
concentrated in two Bell Laboratories groups — 
the SAFEGUARD System Design Department and 


' the SAFEGUARD System Evaluation Department. 


The System Design Department generated re- 
quirements for the various subsystems based on 
the overall design. Implementing these require- 
ments was delegated to various project man- 
agers. The System Evaluation Department 
concentrated, at least initially, on evaluating the 
design, i.e., the requirements, rather than the 
implemented system. Neither of these depart- 


’ ments was responsible for coordinating all im~ 


plementation activities and no other organization 
was assigned that responsibility. Therefore, 
coordination had to be supplied by the individual 
project managers and higher levels of manage- 
ment. 


The results were incompatibilities in system 
interfaces; significant delays in correcting sys- 
tem requirements; delayed awareness of diffi- 
culties; and lack of adequate system evaluation 
of process design, program execution times, 
missile and radar interfaces, and the manual 
display and control subsystem, All of these 
areas were corrected by individual project man- 
agers but only at the cost of added effort and 
delay. 


In future projects, a system coordination 
group shoutd be established within the systems 
area. The group should be responsible for (1) 
coordinating all implementation, (2) interface 


compatibility, (3) coordinating system evalua- 
tion, (4) establishing and achieving project 
schedules, and (5) technical reviews of system 
design, system evaluation, implementation, and 
test programs. In addition, the group should 
ensure that lessons and techniques learned from 
the prototype system are transferred to the 
tactical design. The group should act asa 
technical contributor to all of the above ac- 
tivities, not just as an administrative staff 
responsible only for standards, schedules, 

and reporting. 


System Maintenance Organization 


Most SAFEGUARD designers recognized the 
importance of maintenance, and considerable 
effort was devoted to maintenance by individual 
design groups. However, there was no centra- 
lized guidance for maintenance design, and re- 
sults were less than optimum. For example, 
coordination of status reports and error respon- 
ses from the various subsystems could have 
been improved, and documentation and testing 
of the overall maintenance system could have 
been better. 


To get a better maintenance design, an organ- 
ization with the following charter should have 
been established: 

e Develop and maintain system and subsys- 


tem maintenance requirements consistent 
with the system availability goals 


e Guide selection of maintenance techniques 
and tradeoffs in each hardware and soft- 
ware design area : 


e Guide development of operations and 
maintenance procedures and the associ- 
ated documentation 


e Develop plans for system-level tests of 
maintenance tools (especially for real- 
time operations). 


Like any other element in a system, main- 
tenance requirements will continually evolve as 
system design evolves. These requirements 
and their implementation are highly dependent on 
system Availability/Reliability goals (which 
themselves may change with time). Thus, it is 
important to keep system maintenance require- 
ments up to date and appropriate to the system's 
primary mission. 


Unified Responsibility for Design and Development 


The success of a complex system, including 
its ability to operate on demand, depends on the 
availability and reliability of every essential 
element in it. Thus, "system" cannot mean 
portions of an overall complex, partitioned to 
fall within predetermined administrative juris- 
dictions; no element is separable if its failure 
would prevent the system from fulfilling its 
operational task. In SAFEGUARD, the critical 
complex includes support facilities, such as 
power, environmental cooling, and communica- 
tions, as well as the technical equipment, A 
' diesel engine, a cooling system fan, or a data 
transmission circuit may be just as crucial to 
battle readiness as a data processor unit or a 
missile guidance set. 


An important reason for the success of the 
SAFEGUARD project was that responsibility 
for the design and development of essentially 
the entire system was concentrated in one 
organization. The only exceptions, the Tactical 
Support Equipment (TSE) and the communication 
system, caused significant problems. Also, 
there were difficulties because responsibility 
for training, supply, and maintenance was 
separated from the development responsibility. 


Because the communication system's techni- 
cal direction and funding were under the 
SAFEGUARD Communications Agency (SAFCA), 
not the SAFEGUARD System Command (SAFSCOM), 
issues which could not be settled mutually had to 
be resolved by the SAFEGUARD System Manager. 
As a result, some problems were ignored and 
others took more time and effort to resolve than 
necessary. There was also a tendency to insu- 
late communications suppliers from Bell Labora- 
tories designers, probably to minimize the num- 
ber of design changes. But this impeded liaison 
on the working level, leading to poor under- 
standing of how the communications interfaces 
worked and ultimately to interface problems. To 
try to coordinate communications system design, 
frequent meetings were held (typically monthly). 
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These meetings used up time and manpower and 
required attendance by many agencies and com- 
panies, but they were no substitute for direct 
working-level contact among designers. 


With the TSE, the prototype test site's out- 
standing success in meeting objectives would 
have been impossible without unified authority 
for operating and maintaining both technical and 
support facilities. Many problems surmounted 
only with difficulty (e.g., the problems with the 
Meck power plant) could have been lessened or 
eliminated if such authority had started earlier 
during design, procurement, and installation. 

At the tactical site, placing more of the admini- 
strative responsibility for TSE with the Weapon 
System contractor would have allowed more 
efficient operation with fewer problems and 
delays. During a demanding test and installation 
program, it is impossible to attain either ade- 
quate speed of response or a common view of 
priorities with divided authority. Hence, unified 
responsibility for the total system, including 
both technical and support facilities, is ex- 
tremely important. 


Management 
Subcontractor Arrangements 


The size of the development required that 
design work be assigned to subcontractors and 
responsibilities be shared with government 
agencies. The production phases required de- 
cisions as to which potential suppliers should 
receive contracts. The success of the project 
attests that almost all of the arrangements with 
subcontractors and agencies were quite success - 
ful; however, here too, there were also some 
difficulties. ; 


Arrangements involved a wide range of sub- 
contractors and items. For example, Martin 
Marietta for development and manufacture of 
the SPRINT missile, IBM for software develop- 
ment, a manufacturer other than the design 
agency for production of missile motor cases, 
the Atomic Energy Commission (AEC) and 
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its subcontractors for design and manufacture 
of the warheads. 


Subcontracting work successfully requires 
attention to things which are, for the most part, 
obvious. However, these matters are so vital 
that elaboration is in order. 


Consider first the design responsibility that 
the prime contractor gives to a subcontractor. 
Requirements must be consistent, controlled by 
the prime contractor, and understood well by 
each party. Note that requirements need not be 
perfect and that during the development they will 
change. 

Ways to evaluate progress should be care- 
fully determined before the subcontract goes 
into effect and then followed tenaciously so that 
real status is known by the technical project 


" management on each side of the interface. Be- 


cause requirements do change, progress will 
necessarily be assessed against a moving base, 


Contracts and other formal arrangements 
must not impede the flow of information or in- 
hibit changes. They should encourage progress, 


_ not stifle it. 


The method for subcontracting the software 
development was somewhat unique. Work was 
broken into a collection of well-defined relatively 
small tasks that could be handled between prime 
and subcontractor at a first-line supervisory 
level. Progress was rated monthly by the prime 
contractor's supervisors, and the rating deter- 
mined the award to the subcontractor on the 
cost-plus-award-fee contract. 


Extreme care should be taken when it seems 
desirable to award manufacturing contracts di- 
rectly from the government to other than the 
subcontractor who did the original design. If 
this is done with items that are intricate or use 
new technology, the expertise of the original 
designer is lost. Also, the expertise of the 
prime contractor in making system tradeoffs 
with respect to the item is lost. This kind of 
"breakout" should be used only where items are 
quite stable. 


When an item involves multiple government 
and contractor agencies, such as development 
of a missile warhead, it is obvious that the re- 
sponsibility and requirements assigned to each 
agency must be considered with care for all 
phases of the program. With warhead develop- 
ment, the designs and interfaces could have 
been simplified if complete responsibility, in- 
cluding the adaption kit, had been delegated to 
a single agency. Again, communication, flexi- 
bility, and constant monitoring are required if 
development is to be effective. 


In summary, on a big project, assigning 
work to subcontractors is absolutely necessary, 
can be handled successfully, and requires 
constant management attention. 
Cost-Plus-Award-Fee Contracting for Software 
Development 

On the SAFEGUARD project, a large part of 
the software development had to be subcontract- 
ed. This posed a difficult problem, because 
the software had to be of high quality and be 
delivered on time, in spite of many requirement 
changes and complex interfaces. With all these 
constraints, development problems had to be 
sensed rapidly and accurately, and acted on 
promptly and effectively, or else development 
would get out of control. The key need was for 
close and continued attention to the subcontracts. 


To attract and hold the attention of subcon- 
tractors, the profit from the job was determined 
by job performance. In principle, the Cost-Plus- 
Incentive Fee (CPIF) contract does this by ad- 
ding a fee determined by applying a previously 
agreed-upon formula to objective measurements 
of cost and/or performance and schedule events, 
on completion of the work, Incentive fee con- 
tracts were used effectively on many parts of 
the SAFEGUARD development, However, CPIF 
contracts are difficult to use for developing 
complex software, because it is impracticable 
to set up predetermined performance goals to 
measure against the final product. 


The Cost~Plus-Award Fee (CPAF) contract 
overcomes this handicap by providing that the 
fee be determined in real time and based on the 
subcontractor's performance as judged sub- 
jectively by the customer, The CPAF contract 
is a cost-reimbursable, level-of-effort arrange- 
ment in which the fee to be paid for each (pre- 
determined) period is based on the customer's 
unilateral judgment of the supplier's perfor- 
mance, measured against previously agreed- 
upon subjective performance criteria. The fee 
is not subject to change. This type of contract 
had been used to some limited extent by NASA 
and the Navy, but was not in general use. 


The SAFEGUARD CPAF subcontract for 
software development was in operation for 
more than four years, involved up to about 
800 people, and as of October 1974, covered 
over $130 million. It has been a good vehicle 
for dealing with a large, complex, dynamic 
problem, where the customer needs as good a 
job as he can get, and ontime. This type of 
contract requires good faith between customer 
and supplier, and substantial monitoring and 
evaluation. The format encourages good cus- 
tomer-supplier communications and the manage- 
ment involvement that is necessary for success- 
ful performance. The improved visibility of 
problems makes it possible to solve them 
quickly. 


Incentive Contracts 


Traditionally, during large, long-term 
development projects, principal events are used 
to demonstrate the achievement of significant 
milestones. Most military contracts now in- 
clude incentives — contractually established 
monetary awards (positive or negative) —for 
achieving certain events. Many such incentive 
events were scheduled and successfully achieved 
during the SAFEGUARD development. The 
event system was valuable in demonstrating that 
performance requirements were being met and 
in encouraging project-wide planning. Further- 
more, the events were interim goals, each 
clearly supporting and contributing to ultimate 


TI-12 


success, so that morale was boosted by a sense 
of achievement when goals were reached. The 
monetary awards associated with incentives 
can provide these same important advantages. 
However, requiring the completion of. certain 
events in the contract ensures that they are 
scheduled, while the monetary awards ensure 
proper management attention. 


Incentive contracting has potential disadvan- 
tages as well as advantages. Based on the 
SAFEGUARD experience, the following cautions 
and recommendations are given. 


e Incentive contracting of performance, 
schedules, and.costs is beneficial only if 
firm performance requirements, schedules, 
and costs can be negotiated. The effec- 
tiveness of incentives in state-of-the-art bs 
development projects is severely limited, as 
because milestones cannot be easily identi- 
fied and costs are difficult to negotiate. 
Incentive contracting loses many of its 
advantages if the contract has to be re- 
opened because of major changes in re- 
quirements and schedules. If this 
happens, a contractor fully aware of 
his problems will make every effort to 
"get well" as part of the change negotia- 
tions. 

e Incentive events must be significant, well- 
defined, and carefully chosen in-line 
milestones that must be reached to com- 
plete the project. They should be major 
performance or schedule achievements 
that require the success of many lesser 
milestones. Consequently, they should 
not be ends in themselves, and achieving 
them should not divert a substantial por- 
tion of the project's resources. Further- 
more, if conditions change and an incen- 
tive event no longer serves its original 
purpose, the military and contractor 
should immediately negotiate to remove 
or modify it. To help avoid excessive 
diversion of resources, limit the time 
allowed for demonstrating an event. 


e@ Establish incentive monetary awards only 
for results that are useful to the project. 
For example, an award should not be 
given for delivering a unit before it can 
be used. Similarly, an award should not 
be established for greater power output 
than other elements can handle or the 
system can use. Sound technical and 
business management skills are needed to 
work out the most challenging incentive 
events for a contractor and to assure 
overall success, 


e@ Schedule incentive events infrequently to 
keep them significant and to allow prepara- 
tions to be integrated with normal work. 
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For projects several years long, schedule 
incentive events no more often than every 
three to six months for each major sub- 
system. Events should be scheduled 
approximately eight to twelve months ahead 
of their demonstration date. 


e Well in advance of performance incentive 
events, agree upon a reasonable time period 
or "window" for making the performance 
measurement. Failure to reach the event 
within that time peried should result ina 
maximum penalty. 


e@ Well in advance of a specific incentive 
performance, prepare a "catalog" to cover 
how the test is to be carried out, what 
instrumentation is required, what consti- 
tutes a success or failure, and how to 
score a failure from causes outside the 
contractor's responsibility. Murphy's 
Law states that if there is a chance for 
misunderstanding, it will occur. There- 
fore, careful attention should be given to 
preparing the catalog to make sure all 
factors are considered. 


Reporting Systems 


In large programs such as SAFEGUARD, 
reporting of technical performance, schedules, 
and costs is required for internal control and 
for informing the customer of program status. 
While these program aspects are interdependent, 
they are handled by separate reports and will be 


_ discussed separately. Each reporting system 


evolved over the years to meet changing program 
needs. 


The goal of the reporting system is to convey 
the right level of timely information while con- 
serving the effort required to prepare the report. 
Early in the program, technical progress reports 
were submitted every six months. They were 
difficult to prepare and, because of the interval 
covered, contained much outdated information 
which, while of historical interest, was not of 
immediate concern to program managers. Since 
then, and throughout most of the SAFEGUARD 
program, Bell Laboratories prepared monthly 
technical progress reports for the Army, sub- 
mitting them by the 20th of the following month. 


These reports had enough detail to present 
the current technical status for program man- 
agement and to serve as a permanent record of 
job progress. Additional details were trans- 
mitted less formally by individuals, at meetings, 
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and via memoranda. The monthly technical 
report also gave Bell Laboratories managers 
reasonably detailed information, not only 
about their own activities, but also about other 
phases of the program — a necessary part of 
the program coordination. 


Several weekly TWX reports were sent be- 
tween different project locations. These were 
useful because they were timely and concise. 


For reporting schedules, Bell Laboratories 
evolved the SAFEGUARD Program Schedule 
Charts, which showed program milestone events. 
They were submitted to the Army at monthly 
intervals and were also distributed within Bell 
Laboratories. These significant benchmarks, 
plotted against a calendar grid, supplied the 
information needed to assess program status 
and to coordinate various program activities 
with other Army units, such as the Corps of 
Engineers. 


These schedule charts tracked a limited 
number of easily recognizable milestones. Each 
represented substantial program effort and was 
essential to program completion. The charts 
were backed up by detailed schedules kept by 
each manager of a major subsystem. If the 
dissemination of the schedule charts raised 
questions, the manager could supply the answers 
from his more detailed schedules. The schedule 
charts retained all milestone dates once they 
were established. Where changes were required 
and new targets agreed on, the old dates were 
retained so that the slippages were easily visible. 
The dates when events were accomplished, 
either early or late, were also shown. 


The level of detail in these SAFEGUARD 
Program Schedule Charts proved to be entirely 
adequate for the overall program management, 
They were much preferred to schedule systems 
that showed thousands of events, each involving 
a small amount of effort covering a short time 
interval, Had such a system been used, admin- 
istrative costs alone would have been excessive. 


Cost reporting used a system that summar- 
ized detailed cost information to facilitate 
management review and decisions. The report- 
ing structure showed costs for each subsystem 
with a further breakdown to some half dozen 
separate accounts, In each account, costs were 
shown in four categories: Engineering, Drafting, 
Subcontracts, and Other Direct Charges. At 
the beginning of each year, a spending plan was 
submitted with this same structure. The Finan- 
cial Management Report compared actual month- 
ly costs against the yearly plan, When neces- 
sary, the responsible technical manager sub- 
mitted a revised estimate of the costs for each 
remaining month of the year, with a concise ex- 
planation of the reasons for the revision. 


Although every effort was made to see that 
the Financial Management Report clearly set 
forth program status, an analysis of this re- 
port, together with any recommendations for 
redistributing funds, was furnished to the 
Army each quarter. The analysis and recom- 
mendations were essential to keeping top-level 
management informed. This reporting system 
and its level of detail were adequate for the 
successful financial control of the program. 


Managing the massive, highly complex soft- 
ware subsystem for SAFEGUARD presented new 
challenges, and new systems evolved to control 
it. In general, standardized reporting systems 
met internal project needs fairly successfully. 
They enforced a basic level of planning and | 
stimulated periodic surveillance of status. How- 
ever, different levels of management required 
different levels of detail, and their requirements 
often could not be satisfied by one report. The 
useful life of status information to managers who 
had to take direct action was much shorter than 
the shortest time it took to gather data for a 
project-wide report, prepare the report, and 
distribute it, Also, it was frequently difficult 
for managers to evaluate the accuracy of in- 
formation in written standard reports. Most 
managers relied on direct one-to-one discus - 
sions with their subordinates to obtain informa- 
tion that required immediate action. 
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‘work involved or its importance. 


One of the reporting systems employed was 

the computerized Management Reporting System 

(MRS). Its data base, which had some 3000 

items, contained scheduled start and completion 

dates of various significant activities. Depen- 

dencies between the various items were indica- 

ted. Information was updated each month and 

published as a standard report. The time needed 

to gather, process, and publish information was ce 

approximately three weeks. ' 
In addition to the general positive and nega- 

tive attributes of these standard reports, two 

aspects of MRS stand out: 


1. Schedule problems between different 
project areas were highlighted. 


a 


2. Special weekly reports could be hand- 


tailored for one person. In some cases 
they were more useful than the standard 5 
monthly report. \ 


In software development, numerical meas-~, 
ures of progress, such as the number of rou- 
tines coded and the number of trouble reports 
corrected, were usually found to be of limited 
value. The quantities counted or measured 
were not uniform with respect to the amount of 
Consequently, 
it was very difficult to interpret their signifi- 
cance. 


Principal Events Reports 


The most successful report prepared for 
agencies outside Bell Laboratories was the 
Principal Events Report used for software 
development and system integration. It identi- 
fied a number of important concrete milestones 
and defined them in detail. Many of these 
milestones marked the completion of tests on 
various functional capabilities. Reports on 
such events were normally made by TWX within 
48 hours after their scheduled completion. The 
TW<Xs gave the dates for completion of late 
items, while follow-up TWXs were then sent on 
the rescheduled dates. The Principal Events 
Report, which was issued quarterly, described 
each item, gave its status, and accounted for 
previously completed events. This system of 
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reporting was extremely valuable to higher 
management, with the TWX reports particularly 
useful. 


Miscellaneous 
Alternative Problem Solutions 


There are often many alternative approaches 
to solving management or technical problems. 
In many cases it was more effective to choose a 
good alternative and then carefully implement it 
rather than spend a lot of time trying to optimize 
the choice among alternatives. Often, the initial 
analysis of a problem leads to a complex solu- 
tion which may not really be essential to imple- 
ment, and further review may lead to solutions 
which are "elegant" in their simplicity. Project 
managers should repeatedly challenge their en- 
gineers to seek simple solutions to design prob- 
lems. 


In Several instances, limited budgets led to 
modified requirements and less complex and 
costly designs. Constraints on dollar resources 
can establish hard priorities and stimulate sim- 
pler solutions. This was well expressed by 


' Robert Townsend:* 


"A tight budget brings out the best 
creative instincts in man. Give him 
unlimited funds and he won't come 
up with the best way to a result, 
Man is a complicating animal. He 
only simplifies under pressure. 

Put him under some financial 
pressure. He'll scream in anguish. 
Then he'll come up with a plan 

which, to his own private amazement, 
is not only less expensive, but also 
faster and better than his original 
proposal, which you sent back." 


Independent Testing Operations 


Inevitably, the time allocated to hardware 
installation and testing in any big system will be 
compressed as much as possible. This obvi- 
ously makes it desirable to parallel operations. 
However, in complex systems the required test- 
ing is also_unusually complex. When the system 


*Up the Organization (New York, Knopf, 1970). 
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is controlled by a centralized data processor, 

as in SAFEGUARD, the tests must usually in- 
clude the data processor, so the amount of par- 
allel testing possible is limited, Using relative- 
ly inexpensive minicomputers for much of the 
early testing can alleviate this problem. The 
savings from reduced installation and test time 
may be much greater than the costs of using 
minicomputers, One example of this approach 
concerned the Remote Launch Equipment (RLE). 


A one-farm, two-missile prototype of the 
RLE had been tested at Kwajalein, and the 
tactical hardware had been given limited string 
testing in North Carolina. The first attempt 
to operate in a full four-farm configuration, over 
actual data links with a full complement of ac- 
tive launch cells, took place during installation 
and testing at Grand Forks, North Dakota. 
Therefore, rather complete tests were neces- 


“sary. 


During planning, it was predicted that when 
unit tests of RLE were complete, the ensuing 
system tests would require full-shift operation 
on most working days for several months. 
Schedule conflicts precluded timely completion 
of RLE system testing under control of the 
SAFEGUARD data processor. So a minicom- 
puter, with a hardware interface unit and appro- 
priate software, was temporarily installed at 
the tactical site to simulate the data processor. 
A similar installation had been used success- 
fully at Meck Island during the prototype remote 
launch tests and at North Carolina locations for 
string tests. With the minicomputer, the tests 
were completed on schedule. The minicomputer 
also served as a diagnostic tool for difficult and 
complex design troubles, and surpassed the 
power of the Maintenance and Diagnostic (M&D) 
System and the built-in self-checks. 


Communications for System Tests 


Testing a system ina building as large and 
complex as the Missile Site Control Building 
(MSCB) requires a lot of internal communication, 
and running tests in several buildings at sites _ 


many miles apart is even more difficult. Care- 
ful planning is required for the communication 
system used during this testing. Instead of 
planning separate communication systems for 
testing and tactical operations, one should use 
the tactical communication system for testing 
wherever possible. However, nontactical cir- 
cuits are required to support testing, particularly 
in the installation and early test phases. These 
circuits should be constructed around the basic 
framework of tactical communications. Such an 
approach allows an early evaluation of the tactical 
communication system, avoids the disruptions of 
switching from the testing to the tactical com- 
munications, and minimizes the cost of circuits 
required only for testing. This approach is best 
carried out by a single organization responsible 
for planning both the tactical communications 

and the testing communications. 


importance of Test Planning 


It is universally accepted that good test plan- 
ning is important to development of any system. 
For large real-time systems it may well be the 
most important part. Even when its importance 
is recognized, it is very difficult to make the 
best use of testing at each development stage. 
Although test planning in SAFEGUARD was prob- 
ably more extensive than in any other single 
development, additional effort would have been 
worthwhile. 


Many aspects of system development are 
strongly affected by the way tests are planned. 
The following are some of the most important 
effects recognized during the SAFEGUARD 
development, 


e One of the first issues settled was the 
time allocated to system testing. Im- 
mediately after the deployment decision, 
the design, production, site construction, 
and installation had to be scheduled and 
coordinated, Inevitably, the planners 
wanted to achieve the earliest possible 
completion date. Because it hada direct 
impact on the completion date, one of the 
most important decisions was how much 
time to set aside for final system integra- 
tion and test, It was impossible to list 
the problems which would be faced, and so 
it was very difficult to specify the tests 
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and, therefore, a definite time interval. 
For a system as complex as SAFEGUARD, 
the test interval will be between one and 
two years. Hence, the question is an 
important one. 


With any system, the amount of testing 
(and therefore the testing time) is related 
directly, although in a very complicated 
fashion, to system quality. Reducing the 
amount of testing reduces quality, but 
increasing the amount of testing does not 
increase quality at a fixed rate. It is not 
at all unreasonable to limit the time and 
resources used for testing if it is recog- 
nized that doing So will have definite im- 
plications on quality. 


For a system like SAFEGUARD, a limited- 
quality product can be accepted at the out~ 
set of system life. Quality can then be 
constantly improved as testing continues 

at site installations and at the prototype 
development site. This additional testing 
does not have the same incremental cost 
in resources as testing during the develop- 
ment cycle, because most of the resources 
must be available for routine operation. 
For a multisite deployment, the first 
installation need not have the ultimately 
desired quality, because tests can continue 
while other sites are installed. Conse- 
quently, the system test program can 
extend well beyond the first installation 
and perhaps even well beyond the final 
installation in a multisite deployment, The 
planners must understand the implications 
for system quality before the entire test 
plan is finished. 


Another issue which has a major impact 
on schedule is the number of software 
tests. For a complex system, it is always 
possible to conceive of an infinite number 
of tests, so test planners must first es- 
tablish a finite set. Next, project man- 
agers are rarely willing to allocate the 
time required for all the tests, so the 
problem is to select some subset of tests 
which is in some sense optimal. In 
SAFEGUARD, as a first step, the major 
functional capabilities to be used in im- 
plementing the system were listed. Then 
this set of possible tests was analyzed to 
see how it exercised these functional 
capabilities. A choice was then made as 
to whether each capability was to be ex- 
ercised at all, nominally, or stressed 

to some extent. Then, a set of tests 
which implemented these decisions was 
chosen, and software test planning was 
pointed at that specific set. This approach 
SeemS to have produced an adequate testing 
program. 


Detailed test planning for system integra- 
tion, based on experience with the proto- 
type MSR, began in 1970, four years be- 
fore Equipment Readiness Date (ERD). 
Planning considered test facilities (system 
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exerciser, threat tape generation) and the 
scope of testing (threat scenarios, traffic 
levels, system configurations and operating 
modes, threat excursions, confidence 
levels). Planning went on continually from 
1970 until ERD, but even then, late deliver- 
ies of threat tapes caused problems in sys- 
tem test and integration at the TSCS. Al- 
though it is probably impossible to avoid 
this, careful monitoring is essential to 
minimize such problems because their im- 
pact on schedules can be major. In test 
planning, it is important to consider the 
reliability of test facilities. It is tempting 
to reduce the reliability requirements on 
test equipment not required for tactical 
operation (e.g., tape drives), but lower 
reliability will inevitably lengthen testtime. 


As test planning proceeds, there will 
probably be important interactions with 
system design. The earlier these inter- 
actions are recognized, the lower their 
impact on cost, schedule, and system 
performance, Consequently, specifica- 
tion of system requirements should in- 
clude requirements on the subsystems 
needed for testing. 


To illustrate such interaction, when 
design of the system exerciser was well 
along, 2 serious short-time peak developed 
in the data peocsanve requirements to 
test the system at the desired traffic level. 
Providing this capacity by increasing the 
data processing hardware in the system 
exerciser would have been costly. By 
modifying the tactical system design, the 
requirements on the system exerciser 
were reduced and the necessity for the 
additional hardware was thus avoided. 

This design modification did restrict ac- 
tual system performance, although only 
very slightly. If the situation had been 
recognized later, it could have been re- 
solved only by much greater financial 
costs, disrupting the schedule, or limi- 
ting performance. 


Another major question is how much testing 
to do at each installation of the system. 
For SAFEGUARD, it was decided that each 
installation would be tested as thoroughly 
in all respects, including traffic level, as 
the system was during development. 
Hence, each installation was given a com- 
plete system exerciser facility, even 
though this involved substantial cost. Such 
a decision hinges on issues specific to a 
particular system, In the case of 
SAFEGUARD, the major issues were: 


1. Because the system might never be 
battle-tested prior to an actual 
engagement, it would be very 
difficult to determine whether its 
capability was deteriorating unless 
regular exercises could stress it to 
nearly its full extent. 
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2. Because crews must be ready to 
respond in minutes, if not seconds, 
it was important to exercise their 
responses. 


3. It was important to thoroughly test 
each site, because each was assem- 
bled from tens of thousands of sub- 
assemblies, drawers, and racks; 
there were millions of interconnec- 
tions and contacts and countless 
critical signal and timing interrela- 
tions. Ifa system could not be 
tested, it could not be made to work, 
or be kept working. 


e Defining the requirements for data reduc- 
tion of test results is important but diffi- 
cult, In a system as complex as 
SAFEGUARD, every test produces a tre- 
mendous amount of data, For testing to 
proceed at a reasonable pace, the tester 
must be able to look at just the portion of 
the data he's interested in and to obtain it 
in the most easily understood way. How- 
ever, early in the design he is unable to 
specify in detail what data he needs or 
how he wants to see it. Thus, itis diffi- 
cult to build a data reduction facility by the 
time it is needed. In SAFEGUARD, this 
problem was approached by developing a 
series of data reduction systems. While 
this may be the only solution, it did re- 
quire a very substantial effort. By apply- 
ing more pressure earlier in the design 
cycle, designers would be forced to agree 
on a set of requirements to reduce this 
total effort. 


Site for Prototype Testing 


The TSCS, a partial prototype of the PAR 
and MSR, was built for developing software for 
the deployed system. Earlier in the program a 
prototype data processing system had been pro- 
vided for developing the R&D software. Soft- 
ware could be verified with the TSCS only to a 
certain limit; because actual sensor and missile 
ground/interface equipment was lacking, the 
software development had to be completed at 
the field site. These R&D software deficiencies — 
were remedied in the TSCS by including sensor 
parts that had direct or critical timing inter- 
faces with the data processing system and selected 
parts of the missile ground and communications 
subsystem. Simulating responses for the sen- 
sor and other equipment is not a complete sub- 
stitute for the equipment itself. Responses have 
to be limited, and the simulation can introduce 
artificial timing problems. It is difficult to 


anticipate and design a simulation that has all 
the non-nominal and unexpected responses 
which can have serious impact on software op- 
eration. Simulation can only model the hard- 
ware, and the actual hardware may not conform 
to design intent. 


The choice of equipment for the TSCS proved 
to be effective, and software developed and tes- 
ted at the TSCS was brought up rapidly at the 
installation site. The software used to install 
the hardware at the site and later to maintain 
it was complete and of good quality. Not only 
did the high quality of this software allow the 
site installation to proceed quite rapidly, it 
also established a stable base for the more 
orderly development of the applications soft- 
ware at the TSCS. 


Software designed to control hardware not 
included in the TSCS could only be partially 
debugged and tested at the TSCS; testing was 
completed at the tactical site. There was not a 
great deal of this software, but it was clearly 
not as well checked out when it arrived at the 
- site. 


As software was developed at the TSCS, many 
hardware design and manufacturing problems 
were uncovered, Many of the problems were 
corrected before hardware was installed at the 
site and, in almost all cases, solutions develop- 
ed at the TSCS were available for site installa- 
tion before the hardware was needed for the 
system test program, 


The TSCS made site installation very effi- 

_ cient, So that the major efforts could be directed 
to solving problems unique to the site. Besides 
the efficiency gained in installation and check- 
out, the essential completeness of the prototype 
system-level problems could be identified and 
resolved, These problems, which included op- 
erational situations, were found long before they 
would have-been detected at the tactical site. 
Hence, system integration progressed rapidly. 
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Dissemination of Information 


It was hard for people to keep up with overall 
progress and problems of a job as complex as 
SAFEGUARD. To acquaint people with basic 
decisions and problems was essential, but it had 
to be balanced with the cost in time. For higher 
management, the need was amply met by month- 
ly half-day sessions covering technical status 
and project-wide problems. Such meetings keep 
subsystem project heads technically sharp about 
problems in their areas of responsibility ~ 
particularly when the top managers have the 
technical acumen to probe sensitive areas. 
Clerical and support personnel were kept in- 
formed by quarterly filmed progress reports, 
and the inevitable time lag was acceptable for 
this audience. For lower management, there 
were occasional briefings on problems closely 
related to their work, typically on an organiza- 
tional basis. Little in the way of information 
dissemination was done for nonsupervisory tech- 
nical people. 


More time should have been devoted to 
communicating with lower management and 
technical nonsupervisory personnel. The re- 
ports described earlier were good, but they 
were not always very current, could not be 
questioned, and frequently went mmread, A 
better system might have been a half-day of 
several individual talks every month or six 
weeks, Information such as the following might 
have been communicated more effectively: 


@ Problems already solved and reflected in 
decisions. This area is important because 
the decisions can affect people's work 
directly, and the problem-solving tech- 
niques may be applicable elsewhere. 


e Selected tough problems not yet solved. 
The payoff here is to encourage ideas 
from people who may be able to supply 
them. Also, a tough problem can some- 
times be alleviated by energetic action in 
another area. A difficulty is that groups 
are reluctant to discuss a problem not yet 
completely solved, lest it suggest in- 
competence. Management should en- 
courage the airing of such problems when 
necessary. 
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e Problems which have been formulated, 
put where solutions are not at all apparent, 
or are likely to be put off by the pressure 
of events. By raising these problems, 
they can be considered explicitly where 
they would otherwise have to be bypassed 
because of time pressure if left to upper 
management. 


Transfer of Personnel 


. 


On a large development project, information 
must be exchanged between groups working on 
prototype systems and those working on produc- 
tion systems, and between groups preparing 
system requirements and those implementing 


them. The only feasible way to transmit most 


of this information, of course, is in writing or 
verbally, Some of this information exchange 
should occur via transfers of people between 
organizations so that ideas and points of view 
can be incorporated into the work as fully as 
practicable. 


In the short term, transfers reduce the 
ability of the organization losing the personnel, 
However, this short-term cost is more than 
made up for by the long-term benefits of under- 
standing gained by the receiving organization. 


‘On SAFEGUARD, substantial numbers of people 


were transferred from prototype to production 
development organizations and between other 
groups during production development, Even 
more transfer of personnel would probably have 
been desirable. 


Timeliness of Problem Recognition 


It is important that problems be recognized 
quickly, that solutions be carefully planned, and 
that proper resources be applied. Some prob- 
lems which should be addressed early simply do 
not get timely attention. Others are addressed 
too early and inappropriately "solved," only to 
reappear later. 


For example, initial attempts to design 
SAFEGUARD data reduction packages foundered 
because of inadequate attention. They were 
aimed at testing and integration activities then 
several years away, while operating system 
design, language processors, algorithm 
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development, and guidance simulation were com- 
manding prime attention. This tendency to dis- 
count* problems perceived as remote inspace or 
time also hindered communication subsystem 
design. 


The impact of discounting should be minimized; 
it probably cannot be eliminated. Management 
should guard against it by periodic reviews of 
plans, forecasts, and current design activities. 

A comprehensive development plan is a decided 
help. Management should also restructure 
groups or departments as necessary to start 
early attacks on late-maturing design problems. 
Both of these schemes were tried and found 
useful. 


Staff Assistants for Managers 


Staff assistants, called Management Report 
Analysts (MRAs), were assigned to many 
second-level managers with project manage- 
ment responsibilities. The MRAs were, in 
general, college graduates with backgrounds in 
planning, scheduling, and budgeting. They were 
trained in the objectives, procedures, formats, 
and use of the SAFEGUARD Managing Reporting 
System (MRS) and could input up-to-date infor- 
mation into the MRS through their close associ- 
ation with their project manager. 


They also assisted the project managers by 
preparing and controlling budgets, administer- 
ing contracts, planning, scheduling, allocating 
space, arranging personnel moves, recording 
and following up on action items generated at 
project meetings, and performing numerous 
other administrative details. 


Almost all of the managers who were 
assigned MRAs were enthusiastic about their 
usefulness, By relieving managers of many 
purely administrative functions, the MRAs made 
it possible for managers to concentrate on the 
more critical technical aspects of the job. 


*See H. A. Linstone, IEEE Spectrum, April 1974, 
for a discussion of discounting and forecasting. 
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Reference documents for the topics discussed 
in Part I, Chapters 1 through 11, are listed and 
annotated here. The references for each topic 
are arranged and numbered in their orcer of 
appearance in the appropriate chapter. Items 
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Part IV. 
REFERENCE DOCUMENTS 


listed include a broad representation of reports, 
memoranda, technical manuals, specifications, 
and design documents chosen to provide a thor- 
ough historical background for each subject 
area. 
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1. NIKE-ZEUS Guided Missile System — System 


Study Report (U), Vol 1, Bell Labora- 


‘tories, March 1, 1957. (SECRET-RD) 


Discusses the future air defense problem 
and the system requirements composed 

by such a threat. A description of the 
NIKE-ZEUS system appears in Part I, 
Part Il treats, in more detail, the nature 
of the threat, the data-gathering facilities, 
the missile design and guidance, weapon 
capability, system integration and effec- 
tiveness, a proposed test and development 
program, and a resume of exploratory 
development. 


2. NIKE-ZEUS Tactical Controls for Defense 


Against Ballistic Missile — Case 27495 
(U), D. Gillette, Bell Laboratories TM, 
MM-58-4112-20, May 20, 1958. 
(SECRET) 


Discusses NIKE-ZEUS tactical controls 
for the anti-ICBM operation... The subsys- 
tems controlled are the Forward Acquisi- 
tion Radar, the Local Acquisition Radar, 
the Local Defense Command, and a bat- 
tery. The approach is to set up a model 
at a defense system and to cast the sub- 
systems in their appropriate roles. The 
principles of organization and tactical 
control are then investigated. 


3. NIKE-ZEUS Guided Missile System Ballistic 


Missile Defense (U), Bell Laboratories, 
April 1960. (CONFIDENTIAL) 


Describes the present (1960) NIKE-ZEUS 
System. Reflects system improvements 
that have been incorporated since issuance 
of the original system report in March 
1957 (see Reference 1). 


References for Chapter 1 


NIKE-ZEUS System 


4, NIKE-ZEUS Guided Missile System Radars 


(U), Bell Laboratories, June 1960. 
(CONFIDENTIAL) . 
Describes the NIKE-ZEUS radars and 


summarizes their physical and electrical 
characteristics. 


5. A Tactical Philosophy for NIKE-ZEUS (U) ~ 


Case 27495-42, A. R. Eckler, Bell 
Laboratories TM, MM-62-4263-1, 
February 9, 1962. (CONFIDENTIAL) 
Describes tactical philosophy of the 


NIKE-ZEUS system, including engagement 
planning and engagement execution. 


6. Dielectric Lenses — Case 27495-11, 


W. McMahon, W. A. Yager, and 
D. Edelson, Bell Laboratories TM, 
MM-58-112-16 and MM-58-111-11, 
February 21, 1958. 


A preliminary report on a study of mate- 
rials and structures for dielectric lenses. 
Deals principally with spherical lenses of 
the Luneberg type. Loading low-density 
foams with small amounts of metal parti- 
cles of the proper shape can provide 
media with all of the refractive indices 
required. 


7. Target Detector for the NIKE-ZEUS Acquisi- 


tion Radar — Case 27495-44 (U), G. L. 
Gamble, L. W. Jones, and W. F. Miller, 
Bell Laboratories TM, MM-58-4435-1, 
June 26, 1958. (CONFIDENTIAL) 


Describes the target detector for the 
NIKE-ZEUS acquisition radar. This de- 
tector provides averaged positional target 
information in digital form from analog 
signals received from the receivers of 
the acquisition radar. 


8. The Proposed Design of the Track Initiator 


at the Local Acquisition Radar of the 
NIKE-ZEUS System — Case 27495-41 and 
27495-44 (U), A. Ralston, Bell Labora- 
tories TM, MM-58-4111-13, February 4, 
1958. (CONFIDENTIAL) 


Discusses the design of the track initiator 
for resolved ICBM targets. Presents the 
logical design in its overall aspects, along 
with detailed discussion of the logical de- 
Sign of the various components, The 
reasons for using one mode of operation 
in preference to others are indicated. 


9. NIKE-ZEUS DR — Operational Control of the 


High Level Transmitter — Case 27495-64, 
F. J. Schaefer, Bell Laboratories MFF, 
May 2, 1960. 


Describes the switching functions by which 
the power output of the Discrimination 
Radar High Level Transmitter may be 
controlled and directed. Also describes 
the proposed transmitter control layout 
for the DR Control Console. 


10. Description of the Low Power Section of the 


NIKE-ZEUS DR Transmitter — Case 
27495-64, R. E. Mahoney, Bell Labora- 
tories MFF, February 27, 1961. 


Contains a condensed physical description 
of the low-power section of the Discrim- 
ination Radar Transmitter, along witha 
block diagram and description of the cir- 
cuit operation. 


11. NIKE-ZEUS DR — Off-Axis Accuracy — Case 


27495-42 (U), W. L. Gaines and D. M. 
Vanden Akker, Bell Laboratories TM, 
MM-62-6434-4, October 4, 1962. 
(CONFIDENTIAL) 

Discusses the factors governing the accu- 


racy of off-axis measurement of a radar 
system uSing phase monopulse. 


12. NIKE-ZEUS TTR — Modes of Operation — 


Case 27495-42, W. L. Gaines, Bell 
Laboratories MFF, June 5, 1959. 


Lists and briefly describes the three 
principal modes of operation for the 
NIKE-ZEUS Target Track Radar (TTR). 
These differ from those of NIKE-AJAX 
and HERCULES Systems because of the 
extremely short warning before the 
NIKE-ZEUS TTR must be fully 
operational. 


13, NIKE-ZEUS Target Track Radar Transmit- 


ter (U) — Case 27495-42, K. H. Haber, 
Bell Laboratories TM, MM-59-6436- 13, 
October 1, 1959. (CONFIDENTIAL) 
Describes the TTR transmitter, including 
the chirp principle, the generation of 


receiver local oscillator signals, and the 
functioning of each transmitter portion. 


14. Dynamic Analysis of a Three Gimbal Track- 


ing Antenna — Case 27495, D. A. Conrad, 
Bell Laboratories TM, MM-57-114-39, 
September 23, 1957. 


Analyzes a three-gimbal tracking antenna. 
Reasons that, because of a third axis, the 
gimbal design is not wholly determined by 
directing the antenna at the target. A 
coupling of two or more motions of the 
axes fixes the system. The system's 
motion is described by an equation once 
the form's coupling is prescribed. 


15, NIKE-ZEUS — Maximum Range of TTR — 


Case 27495-42 (U), W. L. Gaines, Bell 
Laboratories MFF, January 22, 1962. 
(CONFIDENTIAL) 


Calculates the maximum range of the TTR 
from the radar range equation. 


16, NIKE-ZEUS MTR — Description and Test 


Results of the GS-59208 Transmitter — 
Case 27495-516 (U), D. B. Seamans, 
Bell Laboratories MFF, June 12, 1961. 
(CONFIDENTIAL) 

Outlines the design objectives and gives 


circuit description and typical perform- 
ance data on this transmitter. 
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17. NIKE-ZEUS R&D Program Final Report (U), 


Vol 1 through 6, McDonnell-Douglas 
Astronautics Company, Report SM-49046, 
March 1966, (Vol 1 and 2 SECRET; 

Vol 3 through 6 CONFIDENTIAL) 
Reviews the history of the development of 
the NIKE-ZEUS missile, and includes 


description and specifications for that 
missile. 


18. NIKE-ZEUS Missile Guidance Section 


Seminar (U), Bell Laboratories, 
March 20-22, 1962. (CONFIDENTIAL) 
Describes in detail the philosophy and 


operation of the Mod III guidance section 
for the NIKE-ZEUS missile. 


19. NIKE-ZEUS Defense Center Data Processing 


System Study Report — Case 2'7495-44 (U), 
Bell Laboratories, April 13, 1962. 
(CONFIDENTIAL) 

Summarizes a recent study of the tactical 


ZEUS Defense Center Data Processing 
System. 


20. NIKE-ZEUS — The Target Data Consolidator 


Computer — Case 27495-44, L. L. 
Cochran and E. R. Weir, Bell Labora- 
tories MFF, August 20, 1962. 
Describes the Target Data Consolidator 


Computer and its functions, including 
data processing. 


21. NIKE-ZEUS — Likelihood Ratios ~ Case 


2'7495-42 (U), S. C. Reed, Bell Labora- 
tories MFF, March 2, 1961. 
(CONFIDENTIAL) 

Introduces the concept of likelihood ratios 


and explains their application to the decoy’ 
problem, 


22. Card Changeable Nondestructive Readout 


Twistor Memory — Case 27495-42, 
J. Janik, Jr., Bell Laboratories TM, 
MM-58-4114-4 and MM-4431-2, 


March 10, 1958. 


Describes the storage of information in 
the presence or absence of permanent 
magnets and the twistor. There is a con- 
tinual search for a readily changeable yet 
nondestructive readout memory, one in 
which the information can be punched on 
a card and inserted into the array. 
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2. 


Hardsite Defense (U), Bell Laboratories, 


July 14, 1964. (SECRET-RD) 


Discusses an early study which examined 
the system and component requirements 
for the active defense of hardened sites, 
concluding that effective levels of defense 
can be provided. 


Active Defense of Strategic Missiles, Joint 


ARPA/Air Force Study, Vol 1-4, Bell 
Laboratories, August 25, 1966. 


Presents the results of a joint Army and 
Air Force study conducted by Bell Labora- 
tories to determine the preliminary char- 
acteristics, effectiveness, costs, and 
schedules for the active defense of Minute- 
man, Titan II, and rebased advanced 
Minuteman forces. 


3. NIKE-X Ballistic Missile Defense System — 


System Study Report (U), Vol 1 and 2, 
Bell Laboratories, October 1, 1963. 
(SECRET) 


Volume 1 discusses the threat and the re- 
quirements it imposes on a defense sys- 
tem, presents the general configuration 
of NIKE-X and its expected effectiveness 
against the threat, and gives fairly de- 
tailed descriptions of the subsystems 
which comprise NIKE-X. Volume 2 pre- 
sents detailed technical material in sup- 
port of critical design choices made in 
the course of the study. 


4. Threat Analysis Study for the Secretary of 


Defense (U), Vol 1 and 2, NIKE-X Pro- 
ject Office, Bell Laboratories, and Stan- 
ford Research Institute, October 26, 1964. 
(SECRET-RD) 


References for Chapter 2 


NIKE-X System 


Following a concise description of NIKE-X, 
the physical threat is described. A sys- 
tem operating plan is postulated, giving 
system responses against various aspects 
of the threat. Finally, deployment prin- 
ciples are discussed and quantative esti- 
mates are given for system effectiveness. 


5. NIKE-X Weapon System — Tactical System 
Description (U), Bell Laboratories, 
January 15, 1966. (SECRET) 


Describes the NIKE-X System and its 
subsystems at the stage of development 
reached by 1966. The system by then in- 
cluded a VHF radar and the TACMAR op- 
tion. The reference threats to which the 
system was being designed are given in 
some detail. 


6. NIKE-X Defense Against Light Attacks, Re- 
port to the Secretary of Defense (U), 
NIKE-X Project Office, Bell Laborator- 
ies, and Stanford Research Institute, 
June 10, 1965. (SECRET-RD) 

Describes a NIKE-X System option that 

(1) provides a CONUS-wide defense against 
light attacks via a high altitude barrage 
defense with modified ZEUS missiles, (2) 
provides comparatively light (referenced 
to previous concepts) SPRINT terminal 
defense of high value population centers, 


and (3) provides for orderly growth to 
meet increasingly sophisticated attacks.. 


7. NIKE-X Deployment Study (DEPEX), Report 
to the Secretary of Defense (U), Office, 
Deputy Chief of Staff for Military Opera- 
tions, Dept. of the Army, October 1, 1965. 
(SECRET-RD) 


Describes a four-phase deployment con- 
cept for NIKE-X, initially optimized for 
area defense against a light attack from an 
Nth Country with particular emphasis on 
evolution of a ballistic missile threat from 
the CPR. Also provides for growth to 
meet massive and sophisticated attacks. 12. 
Emphasis is on ZEUS barrage mode for 
area defense, but basically relies on rel- 
atively moderate (referenced to later 
concepts) deployment of system com- 
ponents. 


8. System Study NIKE-X I-67 Defense Deploy- 
ment (U), Vol 1 — System Description, 
Bell Laboratories, July 5, 1967. 
-(SSECRET-RD) 


Describes deployment and operational con- 13 
cept for countervalue (area) defense 7 
against CPR ICBM attack and for counter- 

force (Strategic Offensive Force) defense 

against USSR attack. Area defense was 

designed explicitly to deny damage by un-~ 
sophisticated threats. Utilized PAR and 

SPARTAN as new system elements. 


9, NIKE-X Studies for 1966 (X-66) (U), Vol 1-8, 
Office of Deputy Chief of Staff for Military 
Operations, Dept. of the Army, Septem- 
ber 1, 1966. (SECRET-RD) 14, 


Builds on previous studies with emphasis 
on more extensive range of attack situa- 
tions. Reexamines previous studies. A 
very light area defense concept is postu- 
lated and tested ("Phase 0" of DEPEX), 
with emphasis on CPR. 


10. Improved SPARTAN System Study Report (U), 
Bell Laboratories, April 1, 1968. 
(SECRET-RD) 


Summarizes system studies performed 
from July 1967 to March 1968 concerned 
with improving the SPARTAN missile in 
its area defense role. 


11, NIKE-X Advanced Development, Hardsite 
Defense (U), Vol 1-5, Bell Laboratories, 
September 1968. (SECRET-RD) 


Reports on two system configurations: 

a fixed-radar and a movable-radar system 
to defend the existing Minuteman, rebased 
Minuteman force in harder silos, and a 
new ICBM force in hard-rock silos, The 
five volumes present the summary, threat 


and effectiveness, radar characteristics 
and design, radar operation and data 
processing, and interceptor supporting 
studies, 


Hardsite Interceptor Study (U), Vol 1 - 


DAC-~62407, Vol 2 ~ DAC-62408, 
McDonnell- Douglas Astronautics 
Corporation, November 1968, 
(SECRET-RD) 

Generated realistic interceptor designs 
for engaging ballistic and maneuvering 
threats in defense of hardsites including 


use of information from the ABMDA UP- 
STAGE experiment program. 


NIKE-X — Discrimination Techniques for 


Hardsite Defense (U), N. Levine, (Bell 

Laboratories) and V. Lotsof (Cornell 

Aeronautical Laboratory), June 1, 1966. I 
(SECRET-RD) ! 
Investigates the discriminants which : 

might be effective against sharp, slender ° 


RVs and decoys from 100-kilofoot al- ik 
titude down to 20-40 kilofeet. 


Ballistic Missile Defense, Advanced Devel- 


opment Program, Advanced Data Proc- 
essing, Vol 1, Bell Laboratories, 
September 30, 1969. 


The first of three annual reports; introduces 

the Parallel Element Processing Ensemble 

(PEPE) concept and details its architecture 

and software and initial simulations. | 


15. IEEE COMP CON '72 Digest: 


PEPE Computer Architecture, B. A. a 
Crane, M. J. Gilmartin, J. H. Huttenhoff, Ce 
P. T. Rux and R, R. Shively 


The PEPE Support Software System, ; 
D. E. Wilson 


Application of PEPE to Radar Data Proc- 
essing, G. D. Bergland andC. F, 
Hunnicutt 


Parallel Processing of Ballistic Missile p 
Defense Radar Data with PEPE, J. A. (es 
Cornell. 
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17. Ballistic Missile Defense, Advance Develop- 


20. Ballistic Missile Defense, Advanced Develop- 


These papers present a brief overview of 
the characteristics, PHSD test implemen- 
tation, and performance of PEPE in a 
general distribution publication, It was 
presented as an example of "Innovative 
Architecture, '' the theme of the Confer- 
ence. 


16. Ballistic Missile Defense, Advanced Develop- 


ment Program, Advanced Data Processing. ai. 


(U), Vol 2, Bell Laboratories, September 
30, 1971. (SECRET) 

Presents an overview of the PEPE IC 
Model, details and results of PEPE applica- 
tion studies to Ballistic Missile Defense, 


ZOS, PHSD and Off-loading, and results of 
hardware implementation studies. 


22. 


ment Program, Advanced Data Processing 
(U), Vol 2, Bell Laboratories, September 
30, 1969. (SECRET) 

Presents the results of studies of the 
Application of PEPE to SAFEGUARD, 


VIRADE, and to Coherent Waveform 
Processing. 


23, 


18. Ballistic Missile Defense, Advanced Develop- 


ment Program, Advanced Data Processing, 
Vol 1, Parts 1 and 2, Bell Laboratories, 
September 30, 1970. 


This second annual report presents a de- 

tailed description of the Integrated Cir- 

cuit (IC) PEPE model brassboard hard- 

ware and its support software and the 

PASS II evaluation studies. = 


19. Ballistic Missile Defense, Advanced Develop- 


ment Program, Advanced Data Processing 
(U), Vol 2, Bell Laboratories, September 
30, 1970. (SECRET) 

Presents results of GPSS simulation studies 
of Ballistic Missile Data Processing and 


design alternatives and a study of the appli- 
cation of PEPE to SPRINT missile guidance. 


25, 


ment Program, Vol 1, Advanced Data 
Processing, Bell Laboratories, September 
30, 1971. 


The third annual and final report of PEPE 
studies at Bell Laboratories. Presents 
an overview of the PEPE system, hard- 
ware and software, and the principal 
final year studies and demonstrations, 
ZOS, PHSD, and offloading. Includes an 
ee to proposed LSI implementa- 
ion. 


NIKE-X — Critical Review of BTL Optical 
Discrimination Program (U), Bell Labor- 
atories, April 1, 1965. (SECRET) 
Reviews the accomplishments and future 
objectives of the optical/infrared measure- 
ment program and data analysis efforts. 


The sensor facilities and operational as- 
pects of these data sources are defined. 


NIKE-ZEUS Guided Missile System Test 
Planning Handbook (U), Bell Laboratories, 
July 1, 1963. (SECRET) 

Describes the early activities and target 
types available to the Reentry Measure- 
ment Program, prior to RMP-A. Sensor 


characteristics. and data collection pro- 
cedures are defined. 


NIKE-X Re-entry Measurements Program 
Targets — Case 27703-1600 (U), R. Flex, 
Bell Laboratories MFF, May 19, 1966. 
(SECRET) 

Provides descriptions of both the RMP-A 
and RMP-B target vehicles. Preliminary 


instrumentation details and objectives are 
presented for the RMV-340 vehicle. 


NIKE-X ~— Summary of Re-entry Measure- 
ments Tests to be Conducted at WSMR 
with NIKE-X Radars — Case 27703-1700 
(U), J. N. Wright, Bell Laboratories 
MFF, December 15, 1964. (SECRET) 


Specifies the reentry test series planned 
for the WSMR and data objectives for the 
DR and TTR. 


The NIKE-X Field Test Program Handbook 
(U), Bell Laboratories, November 1, 
1964. (SECRET) 


Presents the objectives of the Reentry 
Measurements Program and describes the 
targets associated with this program. 
Appendices provide tabulation of equip- 
ment (sensors) locations and a glossary. 


26.. NIKE-X — Description of Reentry Measure- 


ments Program (U), S. J. Buchsbaum, 
L. C.-Hebel, Jr., C. W. Hoover, Jr., 
and R. E. Markle, Bell Laboratories, 
October 1, 1965. (SECRET) 


31. 


Reviews the NIKE-X discrimination pro- 
gram from its infancy in 1960 to 1965, 
Emphasis is placed upon the sleek-cone 
target class and those experimental 
measurements necessary for understand- 
ing the physics of reentry, The experi- 
mental program is explained in detail 
including those to be performed under 


RMP-B. 32. 


27, Radar Observations of Near Wake Velocities, 


RMAR 68-9 (U), J. R. Pignataro, Cornell 
Aeronautical Laboratory, Inc., Report 

UB-1376-S-149, August 1968, (SECRET) 
Describes a discrimination technique de- 


rived from radar observation of wakes of 


reentering objects. 33 


28. NIKE-X Re-entry Measurements Program 


Non-RMV Targets — Case 27703-1600 (U), 
R. Flex, Bell Laboratories MFF, June 9, 
1966. (SECRET) 

Presents parameters and characteristics 
for operational Reentry Vehicles, pene- 
tration aids systems, and research and 


development vehicles flown in the WTR and 
WSMR tests. Booster systems are defined. 


34. 


29. NIKE-X Advanced Development, Analysis of 


Radar Data Obtained During the RMV-A 
Program (U), Bell Laboratories, May 
1967. (SECRET) 

Reports overall results of RMV-A pro- 


gram and applicability to real-time dis- 
crimination. 
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30. NIKE-X Advanced Development — Objectives 


and Description of the Re-entry Measure- 
ments Program Phase B (RMP-B) (U), 

L. C. Hebel, Jr., Bell Laboratories, 
June 30, 1967. (SECRET) 


Describes objectives and plans for RMP-B. 


The Kwajalein Field Measurements Program 
Handbook (U), Bell Laboratories, May 1, 
1968, (SECRET) 


Describes the KTS/NIKE sensor and asso- 
ciated activities in support of offense and 
deiense system development with em- 
phasis on gathering, reducing, and re- 
porting radar data in support of the RMP. 


The Kwajalein Field Measurements Program 
Handbook Supplement (U), Bell Labora- 
tories, June 1, 1968. (SECRET) 


Provides material of special interest to 
test planning and scheduling personnel. 
This supplement also was used to convey 
corrections and additions to the above 
handbook. : 


NIKE-X Advanced Development, On-Board 
Experimenis in RMP-B (U), Bell Labora- 
tories, September 1968. (SECRET) 


Presents a detailed discussion of each ex- 
periment in the RMP-B on-board RMV- 
340 measurement series. The on-board 
measurements contributed knowledge of 
basic vehicle conditions during reentry 
and knowledge of near wake and boundary 
layer properties to aid in the interpreta- 
tion of field measurements. 


Ballistic Missile Defense Advanced Develop- 
ment Program, Bell Sphere Experiment 
(U), Bell Laboratories, July 1, 1971, 
(SECRET) 

Contains the information obtained from the 
Bell Sphere Experiments, The Reentry 


Vehicle chosen for experimental measure- 
ments of physical and chemical processes 





was the sphere, These experiments pro- Lists functional requirements and gives 


: vided measurements of precursor radia- detailed functional schematics, equip- 
tion; plasma sheathing; wake scattering, ment location drawings, etc. Document 

fe resulting from pure~air species, and wake also gives a detailed description of each 
enhancement and elimination, resulting MAR subsystem. 


from additions of electron donor atoms 
and attachment molecule; and on-board 





measurements of boundary layer and 39. TACMAR Reconfiguration to CAMAR (U) ~— 
: hase: clecuien lensiiee. Case 27703-1300, H. D. Hurlbut, 
i. e Bell Laboratories MFF, June 17, 1968. 
7 (SECRET) 

es 35. MAR-I Multifunction Array Radar at White a 

. " Bri : ; pcos Ly 
Sands, Test Planning Handbook (U), Vol ie a 
1 and 2, Bell Laboratories, October 1, TACMARK to CAMAR, 

ee 1964, (Vol 1 UNCLASSIFIED; Vol 2 

} SECRET) 40. NIKE-X Advanced Development — CAMAR 

: Defines the testing program outlined for Program Plan (U), Bell Laboratories, 
the MAR-I at White Sands. In addition, September 15, 1968. (SECRET) 
gives a brief description of the MAR-I 
functional capabilities. Vol 2 offers a de- Presents the CAMAR program plan 
tailed description of the MAR-I system © based upon preliminary study. Includes 
and its subsystems. The descriptions the objectives, brief description of pro- 

eo ; contain tables and figures of the MAR-I gram elements and schedules. 

f radar parameters. 

i nat 41, CAMAR Program Definition (U), Bell 

As 36. MAR-I, An Atlas of the Multifunction Array Laboratories, December 1, 1968. 

i Radar at White Sands (U), Bell Labora- (SECRET) 


tories, October 1964. (SECRET) 
Presents a more detailed description of 
Deals exclusively with MAR-I at White the CAMAR Program and supersedes the 
Sands. The level of detail in the docu- earlier report (Reference 40). 
: ment is greater than any of the others 
“ listed herein. Gives detailed coverage of 


both system design and eee This 42, CAMAR — First Quarterly Report (U), 
e volume contains a profuse collection of : : 
: functional schematics and line diagrams Bt DAD OL AIR ty ABT dys 2 Oe 
i of consoles. (SECRET) 
Summarizes progress for the period 
es 37. NIKE-X Weapon System — Kwajalein System 31 December 1968 through 31 March 
1969. 


Description (U), Bell Laboratories, 


November 30, 1965. (SECRET) 
43. GUARDIAN — Second Quarterly Report, 





Presents complete description of the Z . ‘ 
Kwajalein System, including MAR-I. N. Levine, Bell Laboratories MFF, 
Detailed radar design parameters are August 25, 1969. 
given as well as functional drawings, etc. 

§- Siting considerations for MAR-II are also This is the next quarterly report of 

be shown. rogress on the GUARDIAN Program 

4 (formerly named the CAMAR Program) 

see Reference 42), 


38. MAR Design Manual (U), Bell Laboratories, 
June 1965. (SECRET) 
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1, I-67 System Study — Case 27703-1600 (U), 
J. R. Logie, Jr., Bell Laboratories 
- MFF, August 1, 1967. (SECRET) 
Gives the results of a study to define an 
ABM defense system to counter a minimal 


CPR countervalue threat or a USSR 
counterforce threat, 


2. System Study, NIKE-X I-67 Defense Deploy- 
ment (U), Vol 1 and 2, Bell Laboratories, 
Vol 1, July 5, 1967; Vol 2, October 6, 196 
(SECRET) 

Records the results of a study of the I-67 
deployment of an Antiballistic Missile De- 
fense system. Volume 1 contains a state- 
ment of the objectives of the defense, the 
characteristics of the subsystems, the de- 
ployment and organization, and the effec- 
tiveness against representative threats. 
Volume 2 contains the analyses and ra- 
tionale leading to the selection of the 
systems described in Volume 1. 


3. NIKE-X — CPR and USSR Threat for the 
January 1967 (I-67) Deployment (U) — 
Case 27703-1600, W. F. Bauer and R. B. 
Swerdlow, Bell Laboratories MFF, 
September 6, 1967. (SECRET) 
Describes in detail the Design Threat" 


for the I-67 deployment plan, based on 
USSR and CPR offensive capability. 


4, SENTINEL Siting Analysis — Boston (U) — 
Case 27703-1600, R. S. Rush, Bell Labo- 
ratories MFF, May 2, 1968. (SECRET) 
Evaluates the SENTINEL site options 


selected for locating a PAR and MSR in the 
Boston area, 


7. 
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References for Chapter 3 


SENTINEL System 


5. Air Defense Capabilities of a SENTINEL Site 
(U), Case 27703-1600, Bell Laboratories, 
May 3, 1968. (SECRET) 


Describes the inherent air defense 
capabilities of a SENTINEL site. 


Role of the Northernmost PAR in the I-67 
Deployment (U) — Case 27703-1600, 
J.C. Hemmer, Bell Laboratories MFF, 
August 9, 1967. (SECRET) 


2 


Presents results of a preliminary exam- — 
ination of the role of the northernmost 
Perimeter Acquisition Radar in the I-67 
deployment. 


7. SENTINEL — Perimeter Acquisition Radar 


Face Requirements — Case 27703-1600 
(U), R. M. Hangley, Bell Laboratories 
MFF, January 9, 1968. (SECRET) 
Reports on a study that was conducted to 


determine the required number of faces 
per PAR in the SENTINEL deployment. 


The Hardsite Defense Program — Case 
27709-14 (U), R. S. McCarter, Bell 
Laboratories MFF, December 15, 1967. 
(SECRET) 


Describes the general problem of a Bal- 
listic Missile Defense system and how the 
defense objectives, combined with a sys- 
tem design philosophy, shape the defense 
system within the bounds of the technolog- 
ically possible. 


9. Hardsite Defense — Case 27703-1600, 


R. Emerson Thomas, Bell Laboratories 
MFF, January 6, 1968. 
Discusses and considers the general ques- 


tion of different attacks and defenses for 
hardsite studies. 


10. SENTINEL — MDC Man/Machine Interface 


Functional Requirements for Defense 
Oriented Functions (U) — Case 27703-1600, 
H. D. Todd, Bell Laboratories MFF, 


July 20, 1968. (CONFIDENTIAL) 15. 
Presents the philosophy of man and the 
computer in the Missile Direction Center 
of the SENTINEL System. 


11. Command and Control — Proposed Implemen- 


tation of Nuclear Surety (U) — Case 27703- 
2110, L. R. Bowyer, Bell Laboratories 
MFF, October 16, 1963. (CONFIDENTIAL) 


Proposes a method of controlling nuclear 

surety in the SENTINEL System to ensure 

that defensive missiles are launched and 
detonated only when appropriately 

authorized. ia 


‘12, SENTINEL System — Command and Control 


Program Design Report — Case 27703- 
1500 (U), T. L. Saxton, Bell Laboratories 
MFF, August 14, 1968. (CONFIDENTIAL) 


Describes the Defense Management Pro- 
grams required for implementing a major 
portion of command and control functions 
in the SENTINEL System, and the soft- 
ware interfaces with other major blocks. 


17, 


13. SENTINEL System — PAR Subsystem Com- 


mand and Control Requirements — Case 
27703-1940, R. F. Ricca, Bell Labora- 
tories MFF, January 6, 1969. 


Defines the interface between the Support 
Operation Center and the Perimeter Ac- 
quisition Radar Subsystem. Describes 
tactical and support functions of the PAR 
Manager in the Command and Control 
concept for the SENTINEL System, radar 
test and maintenance philosophy, and 
manual operations of the Manager. 


14. SENTINEL System — MSR Subsystem Com- 


mand and Control Requirements — Case 
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18. 


27703-1400, G. T. Kresan, Bell Labora- 
tories MFF, November 6, 1968. 


Defines the tactical and support functions 
of the Missile Site Radar Manager in the 
overall command and control of the 
SENTINEL System. Outlines the radar 
test and maintenance concept, defines the 
radar status levels, describes the manual 
tactical and support operations of the 
Radar Manager, and describes the hard- 
ware and software required to perform 
the test and maintenance functions. 


The Optimum Availability of the NIKE-X Mis- 
sile Site Radar and Data Processor for the 
I-67 Deployment (U) — Case 27703-1600, 
W. H. Mac Williams, Bell Laboratories 
TM, MM-67-4242-1, October 16, 1967. 
(SECRET) 

Presents an analytical framework for de- 
termining a "best value" of MSR and Data 
Processor availability, with respect to the 
dual-purpose I-67 deployment, and dis- 
cusses the question of whether or not the 
cost of redundant circuits required to 
achieve a stated level of reliability is 
justified. 

Approximate System Availability Models — 
Cases 27703-1600 and 36294-22, 

K. Grace, Jr., Bell Laboratories TM, 
MM-68-6223-8, October 25, 1968. 
Discusses the evaluation of the steady- 


state availability of complex systems with 
limited numbers of spares. 


Approximate Spares Optimization in Complex 
Systems — Cases 27703-1600 and 36294- 
22, S. J. Amster, Bell Laboratories TM, 
MM-67- 6223-8, September 25, 1967. 
Analyzes a spares optimization criterion 
and shows that it yields spares allocations 
very close (if not identical) to the optimal 
criterion where both are applicable and 


can be readily extended to more complex 
system configurations. ; 


NIKE-X SPARTAN Warhead Effects Analysis 
(U) — Case 27703-1600, T. R. Lehnert, 
Bell Laboratories MFF, June 2, 1967. 
(SECRET) 

Considers effect of missile reliability, 


different defensive tactics, and target 
configurations. 


19. Effects of Reduced Missile Reliability on 
SENTINEL Effectiveness (U) — Case 

e 27703-1600, J. E. Keilin, Bell Labora- 

" tories MFF, January 23, 1969. (SECRET) 


Presents an analysis of two types of mis- 
F sile failures: those which occur during 


the first portion of the flight and can be 24 


replaced by launching a substitute inter- 
ceptor and those which occur so late in 
the flight that a substitute cannot be 
er launched, Associates the total in-flight 
missile reliability with penetrator damage 
at two defended sites. 


J 


20. System Readiness Verification — Site and 
" Multisite Exercises — Case 27703-1600, 


January 29, 1969. 





Describes the site configurations and the 
required simulation for each type of Sys- 


go tem Readiness Verification exercises. 

. Proposes an operational doctrine to 

ie accommodate real and simulated intersite 
communications, 


& 21, NIKE-X — Software Generation Breakdown — 
Its Principles and Practices — D.3. — 
Case 27703-1500, D. C. Thayer, Bell 
Laboratories MFF, March 28, 1968. 


Describes the organization, content, use, 


i. and maintenance procedures for maintain- 
: ing the SENTINEL Software Generation 
é Breakdown. 


22. Evaluation through System Simulation — A 
& Preliminary View — Case 27703-1600, 


. D. W. Abmayr and C. P. Neuman, Bell 
‘. Laboratories MFF, April 22, 1968. 
ig Proposes that the most profitable approach 
to system evaluation is through an overall 
a system simulation, examines several 
é simulation approaches, and identifies one 
bee as most promising. 
23, NIKE-X SPRINT Urban Defense Firing 
ee Doctrine — Case 27703-1600 (U), 
; J. W.-Shaw, Bell Laboratories TM, 
: MM-67-6422-7, August 25, 1967. 
&. (CONFIDENTIAL) 
i 
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E. J. Bowers, Bell Laboratories MFF, 25 


27. 


Describes the SPRINT Intercept Allocation 
Program which is being assembled to per- 
form intercept simulations, study firing 
doctrine, determine how various tactical 
problems will be countered, and serve as 
a framework for any future tactical 
program, 


Damage Analysis Tactics Evaluator (DATE) — 


Case 27703-1600, J. R. Evans and D. L. 
Murray, Bell Laboratories MFF, 

May 19, 1967, 

Discusses an ABM defense system tactics 
study model which facilitates the study of 


defense tactics or firing doctrines and 
system performance. 


Optimal Defensive Strategies Using Damage 


Assessment — Case 27703-1600, C. W. 
Spofford, Bell Laboratories TM, MM-67- 
4263-11, August 25, 1967. 


Examines the advantages gained by the 
defense in assessing damage between 
waves of an offensive missile attack, and 
the effect of this assessment on the opti- 
mal offensive and defensive strategies. 


26. SPRINT Firing Doctrine (U) — Case 27703- 


1600, J. W. Shaw, Bell Laboratories MFF, 
October 9, 1968. (SECRET-RD) 


Presents the figures and notes used in a 
briefing given to the October 3, 1968 meet- 
ing of the SPRINT Vulnerability and 
Effects Working Group. Covers (1) frat- 
ricide and lethality, (2) how SPRINT is to 
be used, (3) SPRINT-SPRINT spacings, 

(4) use of SPARTAN and SPRINT in the 
same battle space, and (5) current esti- 
mates of miss distance, 


Penetrations of the Defense Due to Battle 


Space Limitations and Leakage — Case 
27703-1600 (U), J. E. Keilin, Bell 
Laboratories MFF, February 19, 1969. 
(CONFIDENTIAL) 


Plots the probability of no penetrations 
and the expected number of penetrators 
for various values of arrival probability, 
defensive single-shot kill probability, 
number of successful arrivers required 
to guarantee penetration, and the number 
of attempted enemy launches. 


28. SENTINEL - Missile Site Radar Performance 


Requirements (U) — Case 27703-1600, 
R, A. Dayem and R. A. Marth, Bell 
Laboratories MFF, January 15, 1968. 
(SECRET) 


Presents the performance requirements 
placed on the Missile Site Radar (MSR) 
hardware to ensure fulfillment of its role 
in the SENTINEL Defense System. Dis- 
cusses the functions, threat, and environ- 
ment appropriate to the MSR hardware. 


29. SENTINEL — Perimenter Acquisition Radar 


Performance Requirements — Case 27703- 
1600 (U), R. S. Larkin and T, E. Lenigan, 
Bell Laboratories MFF, January 15, 1968. 
(SECRET) 


Presents the performance requirements 
laced on the Perimeter Acquisition Radar 
PAR) hardware to ensure the fulfillment 

of its role in the SENTINEL Defense Sys- 

tem. Discusses the functions, threat, and 
environment appropriate to the PAR. 


33. SENTINEL System - Basis for the Develop- 


ment of the SENTINEL Data Processing 
System Hardware — DPS-2 — Case 27703- 
1500, T. H. Crowley, Bell Laboratories 
MFF, July 18, 1968. 

Describes the basis on which the develop- 


ment of SENTINEL Data Processing Sys- 
tem hardware is proceeding. 


34. NIKE-X — Functional Generation Breakdown 


for the 1-67 Deployment — Cases 27703- 
1500 and -1600 (U), J. F. McDonald, 

G. W. McPheters, T. L. Saxton, and 

P, R. Sternfels, Bell Laboratories MFF, 
November 28, 1967. (SECRET) es 
Outlines the structure (Functional Genera- igs. 
tion Breakdown) that will be used to specify 
the I-67 system software requirements. 
Identifies ten data processing functional 


configurations, and presents a functional 
generation breakdown for each. 


35. SENTINEL Support Software Philosophy and 


30. Constraints on Attack Density Due to 


SPARTAN-Induced PAR Blackout (U) — 
Case 27703-1600, M. J. Spahn, Bell Labo- 
ratories MFF, October 19, 1967. (SECRET) 
Describes studies made to determine 
traffic limitations imposed upon the 


SENTINEL System by self-blackout 
under certain conditions, 


31. NIKE-X SPRINT Kill Probability ~— Case 


27703-1900 (U), J. M. Protzman, Bell 
Laboratories MFF, February 21, 1968. 
(SECRET) 

Describes the kill model adopted, the 


application of the kill model, and the 
values of kill probability which result. 


32. Graphs of Kill Probability as a Function of 


Miss Distance for SPARTAN Exoatmo- 
spheric Intercepts (U) — Case 27703-1600, 
J. E. Keilin (UNIVAC), Bell Laboratories 
MFE, November 27, 1967. (SECRET) 
Develops probability equations to predict 
kill probability as a function of miss dis- 


tance, in the light of more recent infor- 
mation, and charts the results, 
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Structure — Case 27703-1500, W. 
Hagerbaumer, R. Held, J. J. Kaplan, 
and J. G. Standley, Bell Laboratories 
MFF, January 15, 1969. 

Presents design concepts for the 
SENTINEL Support Software (as distinct 
from the R&D Support Software), and 


describes the interrelationships among 
various support facilities, 


36. Programming System for NIKE-X, Language 


Processor Requirements Temporary 
Manual, Bell Laboratories, May 1, 1967. 


Considers the goals, capabilities, and 
restrictions of: real-time and non-real- 
time programs; the operating system 
(NEXOS); and the program development 
facility (NETSS). 


37, NIKE-X - Meck Test Program — Case 27703- 


1600(U), S. F, Knakkergaard, Bell Labora- 
tories MFF, March 5, 1968. (SECRET) 


Outlines currerft plans for developing and 
testing the SENTINEL Sysiem capabilities 
at Meck. These plans reflect the impact 
of the deployment decision and recent 
changes in emphasis and schedules. 


Ty 
att 


1. SAFEGUARD System — Grand Forks IOC 
System Capability Definition (U) — Case 
be - 27950-1600, H. D. Hurlbut, Bell Labora-~- 
tories MFF, July 8, 1974. (SECRET) 


a Summarizes the principal SAFEGUARD 

ES System capabilities that will have been 

; demonstrated at Grand Forks for Initial 5. 
Operational Capability (IOC). In addition, 

'. discusses capabilities included in the sys-~ 

fe tem but not tested by IOC. Also gives a 

Rl listing of capabilities once considered for 
SAFEGUARD but no longer part of the 

es system. 

be 2, SAFEGUARD System ~ GF ERD System Capa- 

oe bility Description — Revision 1(U) — Case 

: : 27950-1600, J. M. Wuerz, Bell Labora- 

Re tories MFF, June 18, 1973. (SECRET) 

e: Defines the SAFEGUARD System Capa- 

f bilities which will be available at Grand 6. 

i. Forks by the October 1974 Equipment 

shy Readiness Date (ERD). Capabilities are 

iven in terms of (1) the threat scenario, 

ge 2) traffic levels, (3) available functions, 

i. and (4) confidence. 

& x 


3. Terminating Pindown Defense Operations — 
Case 27950-1600 (U), K. A. Raschke, 
Bell Laboratories MFF, May 28, 1971. 
(SECRET) 





Emphasizes the basic purpose of the pin- 
down defense mode, and explains its basic 
vulnerabilities. Notes the current proce~ 
dure for ending counter-pindown engage- 
ment planning, and gives three alterna- 
tives to the present rules. 


f 
be. 


fou 
&2 


4, SAFEGUARD Firing Doctrine (U) — Case 
27950-1600, K. A. Raschke, Bell Labora- 
tories MFF, October 16, 1970. (SECRET) 
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References for Chapter 4 


SAFEGUARD System 


Provides an up-to-date comprehensive 
summary of firing doctrine for the Phase 
2a SAFEGUARD deployment, The infor- 
mation is based primarily on the June 15, 
1970 issue of the SAFEGUARD Data Proc- 
essing System Performance Requirements. 


The SAFEGUARD Response to an Attack of 
Less-Than-Massive Magnitude (U) ~ 
Case 27703-1600, K. A. Raschke, Bell 
Laboratories MFF, July 31, 1970. 
(SECRET) 
Describes the SAFEGUARD response to an 
attack that is of less than massive magni- 
tude (accidental launch defense mode), 
Considers system operation, Interceptor 


Response procedures, and features inves- 
tigated but not incorporated. 


The Response of the SAFEGUARD System to 
an SLBM Pindown Attack (U) ~ Case 
27703-1600, K. A. Raschke, Bell Labora- 
tories MFF, July 24, 1970. (SECRET) 
Examines the present pindown concept and 
SLBM threat, and the characteristics and 
capabilities of the SAFEGUARD response. 


Considers possible modifications and 
improvements in system response. 


. An Operational Description of the Functions 


of the Elements of the SAFEGUARD Sys- 
tem During Each of the Defense Modes — 
Case 27703-1600 (U), J. R. Logie, Jr., 
Bell Laboratories MFF, February 24, 
1970. (SECRET) 

Documents the functions required at the 


PAR and MSR for the defense modes of 
system operation. 


8. SAFEGUARD System — Operational Con- 


cept — Case 27703-1600 (U), J. R. Logie, 
Jr., Bell Laboratories MFF, May 19, 
1969. (SECRET) 


A design concept paper intended to estab- 
lish a basis for writing a consistent set 
of Data Processing System Performance 
Requirements (DPSPRs). The concept 
covers the defense objectives, command 


Bell Laboratories MFF, December 4, 
1970. (SECRET) 


Explains why the particular system con- 
figurations and design values were chosen 
for the Target Tracking portion of the 
MSR Weapons Process section of the Data 
Processing System Performance Require- 
ments, and provides supporting documen- 
tation. Begins with a brief description of 
overall system operation. 


and control configuration, and SPARTAN, 
SPRINT, PAR, and MSR operation. 
14, SAFEGUARD — Tactical Wake Track De- 


sign ~ Case 27950-1600, J. E. Marowitz, 
Bell Laboratories MFF, February 28, 1974, 


9. SAFEGUARD Attack Assessment — A Pre- 
liminary Analysis of PAR Capability (U) — 
Case 27950-1600, R. S. Rush, Bell Labo- Describes the DG-5 Wake Track design. 


: Gives a general description of the overall 
ratories MFF, June 5, 1973. (SECRET) design philosophy and the implementation 


Documents an analysis undertaken to eval- of the design by the track function. 


uate Perimeter Acquisition Radar capabil- 


wane assessment and early 15. SAFEGUARD System — Performance of Tac- 


tical Kill Assessment (U) — Case 27950- 
1600, G. C. Smith, Bell Laboratories 
MFF, April 14, 1973. (SECRET) 


Discusses SPRINT kill probability under 
various engagement assessmenis. 


10. Terminal Defense Degradation from Low 
Altitude Offensive Blackout — Case 27950- 
1600 (U), L. Behrendt, Bell Laboratories 
MFF, July 12, 1972. (SECRET) 
Delineates nuclear ''blackout" effects in a 


terminal defense area for various sizes of 
penetrator weapons. 


16. SAFEGUARD System — Data Processing Per- 
formance Requirements Missile Site Data 
Processor (U), Part 1, G-437953, Case 
27950-2110, Bell Laboratories, Revision 
December 1, 1969. (SECRET) 


11. SAFEGUARD Attack Assessment — A Pre- 
liminary Analysis of MSR Capability (U) — 
Case 27950-1600, R. S. Rush, Bell Labo- 


This document was superseded by 
ratories MFF, May 14, 1973. (SECRET) 


Reference 39, Part 1. 


Documents an analysis to support an eval- 

uation of the Grand Forks Missile Site 17. SAFEGUARD System — Data Processing Per- 

are he force to characterize certain formance Requirements Missile Site Data 
Processor (U), Part 2, G-437953, Case 

27950-2110, Bell Laboratories, Revision 

October 15, 1969. (SECRET) 


12, Interceptor Capability in Command Guidance 
Systems — Case 27950-1600, C. Imagna, 


Bell Laboratories MFF, October 20, 1970. This document was superseded by 
Reference 39, Part 2. 

Presents an improved solution to the com- 

mand guidance system problem of choosing 

the best point on the capability surface of 18. SAFEGUARD System — Data Processing Sys- 
the guidance loop and computing the steer- 
ing command which will move the inter- 
ceptor to this point at intercept time. 


tem Performance Requirements PAR 
Data Processor.(U), G-437954, Case 
27950-2110, Bell Laboratories, Sep- 


13, SAFEGUARD System — The Rational Support- tember 15, 1969. (SECRET) 


ing the MSR Track Performance Require- 


This document was superseded by 
ments (U) — Case 27950-1600, A. W. Besse, 


Reference 38. 
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19. SAFEGUARD System — CLC Throughput 


Study — Status Report — Case 27950-1500, 
D. B. Knudsen, Bell Laboratories MFF, 
January 9, 1974. 


Reports on the characterization of the 
CLC-2 hardware. The CLC-2 is a large, 
high speed, multiprocessor, general 
purpose computer which performs data 
processing for the SAFEGUARD System. 
Presents data on Program Store queueing 
and throughput of a 10-processor, 10- 
Program Store system. 


20. SAFEGUARD System — CLC Throughput 


Study — Case 27950-1500, D. C. Ruberg, 
Bell Laboratories MFF, October 4, 1972. 
Gives a preliminary report on the Central 


Logic and Control 2 throughput work being 
conducted at Madison, N.J. 


21. SAFEGUARD — Meck Test System — IOC 


Characterization, Maximum Data 
Throughput Tests — Case 27950-1500, 

D. L. Fritzsche, Bell Laboratories MFF, 
February 24, 1971. 


Deals with purpose and goals of IOC 
(Input/Output Controller). Describes 
measurement of Indirect Command execu- 
tion times, and maximum data rate to and 
from each peripheral device; measure- 
ment of maximum IOC data throughput; 
simulation of worst-case M-2 Input/Output 
activity for evaluation of IOC capability 
margins, 


22, SAFEGUARD System — Basic Deployment — 


MSR Data Processor Sizing — Case 27950- 
1600 (U), R. T. Herbst, Bell Laboratories 
MFF, October 8, 1971. (SECRET) 


Provides the basis for the recommendation 
that the MSR DPS sizing for the basic 
SAFEGUARD deployment be 10 Processor 
Units, 12 Program Stores, and 14 Vari- 
able Stores, and that the basic deployment, 
2 PARS and 4 MSRs, preserve the option 
to install more than 10 Processors at each 
MSR site. 


23. SAFEGUARD System — Study of EMP Effects 


on-Intrasite Data Communications (U) — 
Case 27950-2110, P. W. Grabow, Bell 
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Laboratories MFF, June 22, 1972. 
(SECRET-RD) 


Presents applicable Electromagnetic Pulse 
(EMP) waveforms and spectra for surface, 
air, and high-altitude bursts. Estimates 
the effects of these bursts on intrasite 
data transmission using Lenkurt 46C re- 
peaters with Anaconda‘cable. Indicates 
that SPRINT-type air bursts will not pro- 
duce data errors, whereas surface bursts 
within a Minuteman field and high-altitude 
bursts at any distance should be assumed 
to cause errors in intrasite communication. 


. Functional Description of the SAFEGUARD 


Data Transmission Subsystem — Case 
27950-1100, D. K. Dixon and T. F. 
Turnmire, Bell Laboratories MFF, 
July 23, 1971. 


Presents complete functional descriptions 
of the DTC and DTCA. 


SAFEGUARD System — Tactical Communica- 


tions Criteria (U), 11,425,721 Revision 
H, Bell Laboratories, May 31, 1974. 
(SECRET) 

Presents tactical communication require- 
ments including those for survivability, 


traffic loads, data rates, transmission 
disturbances, and circuit delay. 


Procedures and Tolerances in SAFEGUARD 


Time-Keeping — Case 27950-1500, 
G. L. Gamble, Bell Laboratories MFF, 
February 15, 1972. 


Presents a detailed description of the 

major time procedures to be performed 

at the master time site and at the slave 

ree sites at start-up and on a continuing 
asis. 


27. SAFEGUARD System — System Design Re- 


quirements for Displays and Controls (U), 
Vol 1, 11268704, Bell Laboratories, 
SDRSDCV1@SD##XXXX, June 30, 1974. 
(SECRET) 

Contains a complete functional description 
of the tactical manual actions available 

at IOC at the BMDC, MDC, and PAR, 


and information relating to each console 
position. 


28. SAFEGUARD System — MSR Radar Monitor 


Console Displays and Interfaces (Revision 

1) — Case 27950-1400, G. T. Kresan and 

R. H. Thieme, Bell Laboratories MFF, 
December 5, 1973. 

Describes all Radar Monitor Console indi- 

cators, controls, and interfaces. Incor- 

porates recent functional changes and 33 


reflects all Engineering Change Propos- 
- als that are outstanding for this console. 


29. SAFEGUARD System — Command and Con- 


trol Subsystem — Description of the Mis- 
sile Monitor and Test Console and TTY — 
Case 27950-2110, J. J. Cappiello, Bell 
Laboratories MFF, December 15, 1970. 
Presents a description of the Missile Moni- 
tor and Test Console and its functions. 
Includes status and control signal infor- 


mation related to both remote and local 
missiles and associated equipment. 


30. SAFEGUARD System — Data Management 


Console and Teletypewriter — Man/ 
Machine Description — Case 27950-2110, 
I. A. Kronish, Bell Laboratories MFF, 
October 11, 1974. 

Presents a description of the tasks per- 


formed at the Data Management work 
position. 


31. SAFEGUARD System — Command and Con- 


trol Display Subsystem — Functional De- 
scription of the Data Processing Officer 
Console Position — Case 27950-1500, 

8S. R. Peck, Bell Laboratories MFF, 
September 26, 1972. 


Presents a consolidation of the relevant 
material concerning the Data Processing 
Officer (DPO) console position. This 
material has been combined into a single, 
coordinated design specification: Also 
documents the current design philosophy 
for this operating position, including 
rationale, currently designed capabilities, 
and future expected capabilities. 


32. User Oriented Description of the Maintenance 


and Diagnostic Processor Operating 
System, Version 1 (MDP/OS-1) — Case 
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34. 


35. 


27950-1100, R. A. Buccigrossi, K. J. 
Henderson, and J. R. Shutt, Bell Labo- 
ratories MFF, April 29, 1971. 

Presents a description of the Maintenance 
and Diagnostic Processor Operating Sys- 


tem, Version 1(MDP/OS-1), with its 
associated file on development programs. 


. SPRINT Remote Launch — Equipment Status, 


Control, Readiness Verification, Diag- 
nosis and Maintenance ~— Case 27703- 
1000, D. P. Worrall, Bell Laboratories 
MFF, October 21, 1969. 


Proposes a maintenance concept for the 
electronic equipment being developed by 
Bell Laboratories to support remote 
launchings of SPRINT missiles. General 
testing, fault detection, status reporting, 
fault isolation, repair, and verification 
are considered. The hardware under con- 
sideration includes the Remote Launch 
Data Controller (RLDCT) and the Monitor 
and Control Multiplexer Local (MCML) 
located in the Missile Site Control Buiid- 
ing (MSCB). 


SAFEGUARD System — Description of a 
Logic Simulation Program to Aid in the 
Development of M&D Programs — Case 
27950-1500, H. L. Benoy I andM. P. 
Smith, Bell Laboratories MFF, 
January 10, 1974. 


Describes the use and operation of the 
Maintenance and Diagnostic Logic Simu- 
lator (MDLSIM), a set of programs used 
to aid in developing maintenance and 
diagnostic test programs by simulating 
logic circuits found in the SAFEGUARD 
data processing system. 


SAFEGUARD — Data Processing System — 
Maintenance and Diagnostic Processor 
Controller Functional Description, 
Case 27950-1500, J. A. Meyer and 
F, B. Torres, Bell Laboratories MFF, 
October 25, 1971. 


Presents detailed information on the 
Maintenance and Diagnostic Processor 
Controller, an interface and control unit 
designed by Bell Laboratories for use 
with the modified CDC-1700 computer. 
Provides a general physical description 
of the hardware and details for each part 
of the hardware. 
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36. SAFEGUARD System Software Development 


Plan (U), Vol 1 and 2, G486643, Bell 
Laboratories, July 1, 1971. Vol 1 
(UNCLASSIFIED), Vol 2 (SECRET) 


Describes the various activities and events 
proposed as a means of building the Data 
Processing System software required for 
the deployment of the Phase I SAFEGUARD 
System, and indicatés the relationships 
between the various events. The plan re- 
flecis the principal assumptions, activ- 
ities, and issues that are fundamental to 
the development and deployment of the 
SAFEGUARD Data Processing System 
software. 


37. SAFEGUARD — IBM Support Computer Sys- 


tem Utilization and Performance Guide- 
lines — Case 27950-1500, E. S. Swanson, 
Bell Laboratories MFF, January 20, 1972. 


Specifies guidelines for the practical solu- 
tion of problems pertaining to the detection 
of bottlenecks in the support computer 
configurations, helps evaluate hardware/ 
software changes before and after the 
changes are made, and helps provide the 
best computing service possible given the 
type of load presented to the computer. 


38. SAFEGUARD System — Data Processing Sys- 


tem Performance Requirements, PAR 
Weapons Process (PW1) PAR System 
Exerciser Process (EPX) (U), 11277025, 
L. C. Johnson, Bell Laboratories, 
SRDPARWP@PR##XXXX, June 15, 1970, 
Revised March 28, 1975. (SECRET) 
Contains the Data Processing System Per- 
formance Requirements (DPSPRs) for the 
Perimeter Acquisition Radar (PAR) to be 
used as a basis for developing the PAR 


Weapons Process (PW1) and the PAR Sys- 
tem Exerciser Process (EPX). 


39. SAFEGUARD System — Data Processing Sys- 


tem Performance Requirements, MSR 
Weapons Process (MW1) MSR System 
Exerciser Process (EMX) (U), 11277024 - 
Parts 1 and 2, L. C. Johnson, Bell 
Laboratories, SEDMSRWP@PR##XXXX, 
June 15, 1970, Revised April 7, 1975. 
(SECRET) 
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Contains the Data Processing System Per- 
formance Requirements (DPSPRs) for the 
Missile Direction Center (MDC) to be used 
as a basis for developing the MSR Weapons 
Process (MW1) and the MSR System Exer- 
ciser Process (EMX). 


40. SAFEGUARD System — Data Processing Sys- 


tem Performance Requirements, Ballistic 
Missile Defense Center (BW-1) (U), 
11277026, L. C. Johnson, Bell Labora- 
tories, SRDBMDCW@PR##XXXX, 
November 30, 1970, Revised March 15, 
1975. (SECRET) 

Contains the Data Processing System Per- 
formance Requirements (DPSPRs) for the 
Ballistic Missile Defense Center (BMDC) 


to be used as a basis for developing the 
BMDC Weapons Process (BW1). 


41, SAFEGUARD System — CLC Resource Con- 


figuration and Initialization by the CLC 


Control Facility — Case 27950-1500, 
P. T. Guarneri, Bell Laboratories MFF, 
November 6, 1972. 


Identifies the functions performed by the 
CLC Control Facility (CTL) which result 
in configuration and/or initialization of 
CLC resources, and defines the state of 
these resources when CTL transfers 
execution control to either the Basic or 
the Tactical Operating System. 


42. SAFEGUARD System — Tactical Operating 


System (TOS) Functional Specification ~ 
COXTOSFN@FNO1XXXX, S. A. Svach, 
Bell Laboratories, March 12, 1970, 
Revised January 4, 1971. 


Discusses the functions performed by the 
TOS modules, their relationship to each 
other, and the relationship of TOS to other 
SAFEGUARD Data Processing System 
facilities. : 


43. Error Handling by the Tactical Operating 


System (TOS) — Case 27950-1500, 
J. G,. Standley, Bell Laboratories MFF, 
March 31, 1972. 


Explains the general philosophy and the de- 
tailed methods that TOS will use to handle 
and report error conditions. The general 
error handling philosophy, the TOS struc- 
ture and division of responsibility for 
error processing, and the TOS mecha- 
nisms for error reporting are detailed. 


44, CENTRAN: A Case History in Extensible 
Language Design, Case 27950-1500, 
B. N. Dickman, Bell Laboratories TM, 
TM-74-6623-3, April 1, 1974. 
Presents the design history of CENTRAN 
to describe how and why the computer 


language was designed and how it was 
implemented. 


45, SAFEGUARD System — SAFEGUARD Tac- 
tical Computer Simulator (STACS) User 
Manual (U), IBM Corporation, 
FTXUSERM@UM##XXXX, Revised 
December 11, 1972. 

Describes the use of the SAFEGUARD 
Tactical Computer Simulator (STACS) 
program, with primary emphasis on the 
new STACS Control] language. Encom- 
passes STACS capabilities through Ver- 
sion C. STACS provides facilities for 


unit/task level testing of CLC-2 programs 
in a non-real-time environment. 


46, SAFEGUARD — Configuration Management 
Operating System Manual for Operations 
and Maintenance, SAF-2009, Issue 1, 
Western Electric, September 1974. 
Gives the detailed structure and proce- 


dures for controlling SAFEGUARD hard- 
ware and software. 


47. SAFEGUARD System — Software Configura- 
tion Management Plan, Bell Laboratories, 
DCCMGMNT@SM02XXXX, Revision 2, 
August 2, 1974. 

Outlines the general policies and proce- 
dures to be followed for controlling 
SAFEGUARD software to meet the con- 


tractual configuration management 
requirements. 


48. SAFEGUARD — Tactical System — Patch 
Utility Program User Manual for PUP 
R4/A4 — Case 27950-1500, T. J. Buckley, 
Bell Laboratories MFF, March 27, 1974. 
Provides information on the use of the 
SAFEGUARD Patch Utility Program 
(PUP). This program provides a self- 


documented storage and maintenance 
capability for changes or modifications to 


49, 


50. 


51. 


52. 
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the bound object code generated during 
software development at the tactical 
SAFEGUARD sites (including TSCS). 


A Method to Add Configuration Identification 
Information to CLC Software ~ Case 
27950-1500, R. A. Grubic, Bell Labo- 
ratories MFF, February 15, 1974. 


Describes a method that will allow Central 
Logic and Control (CLC) support software 
to maintain configuration identification 
information on disc. The method will 

aid in maintaining the credibility of 
SAFEGUARD Software by minimizing 
confusion in the disc patching of tactical 
software. 


Execution Preparation Facility (KPF) — 
User Manual, IBM Corporation, 
FEXXPFUS@UM 13XXXX, 

February 3, 1975. 

Describes the capabilities, operation, and 
procedures for using the Execution Prepa- 
ration Facility. This software facility 
prepares a collection of programs and 
data sets for real-time or non-real-time 
execution on the Central Logic and 
Control (CLC2) computer or under the 


SAFEGUARD Tactical Computer Simu- 
lator (STACS). 


SAFEGUARD Tactical System — Proposal for 
Implementation of a System Logging Func- 
tion in the Tactical Operating System 
(TOS) Environment — Case 27950-1500, 
P. V. Guidi, Bell Laboratories MFF, 
August 19, 1970. 

Proposes a unified method for logging and 
recording critical system information 
based on current Tactical Operating Sys-~ 


tem (TOS) Tape Manager, Error Control, 
and DEBUG Histogramming design. 


The Breakpoint Timer — A Proposed Hard- 
ware Facility to Aid in Software Develop- 
ment at the TSCS — Case 27703-1500, 

T. L. Warner, Bell Laboratories MFF, 
February 17, 1970. 
Describes capabilities required of a pro- 


posed new Breakpoint Timer to permit 
on-line analysis of process tests. 
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53. SAFEGUARD System — Concepts and Facili- 


ties of the CLC Monitor — Case 27950- 
1500, T. L. Warner, Bell Laboratories 
MFF, May 25, 1973. 


Presents the functions available through 
the Central Logic and Control Monitor, 
and provides initial information concern- 
ing the user's interface with this subsys- 
tem. The CLC Monitor is an independent 
subsystem which interfaces with the CLC 
to gather data for debugging, tuning, and 
evaluation of both software and hardware. 


54. SAFEGUARD System — PAR-EPX QUICK 


LOOK Data Analysis Tool — Case 27950- 
1500, D. W. Sullivan, Bell Laboratories 
MFF, April 2, 1974. 


Describes a subroutine, QUICK LOOK, 
which can provide an assessment of the 
overall functional performance of the PAR 
Weapons Process during the termination 
sequence of an exercise. 


55. Proposal for SAFEGUARD Data Reduction 


System, Case 27703-1500, P. A. Highland, 
Bell Laboratories MFF, May 12, 1969. 


Outlines the functional requirements for a 
fully developed data reduction system, 
gives examples from typical design areas, 
and proposes a software structure within 
which to develop the capability. Discusses 
the proposed reduction system in terms of 
its flexibility to handle user-developed 
routines, stage-by-stage development of 
capability, machine adaptability, and data 
reduction run structuring. 


56. SAFEGUARD System — System Integration 


and Evaluation Test Plan (U), G-741752, 
Bell Laboratories, July 1974, (SECRET) 


Contains the Weapons System Contractor's 
plan for integrating the major components 
of the SAFEGUARD System. The test plan 
encompasses basic integration tests, 
system-level integration testing, and 
Operational System Readiness Verifica- 
tion (OSRV). 


57. SAFEGUARD System — System Test Specifi- 


cation Grand Forks Minuteman Defense 
Mode System Test (SYS/M3) (U) (80/015), 
M. J. Suralik, Bell Laboratories, 


SIBGMMO03@SP##XXXX, March 15, 1974, 
Revised May 12, 1975. (SECRET) 


Contains the system test specification for 
testing the Perimeter Acquisition Radar 
(PAR), the Missile Defense Center (MDC), 
and the Ballistic Missile Defense Center 
(BMDC) operating in a netted mode and in 
the Minuteman defense mode. 


58. SAFEGUARD System — System Test Specifi- 


cation Grand Forks Accidental Launch 
Defense Mode MSR and PAR Test (U) 
(80/0610), M. J. Suralik, Bell Labora- 
tories, SIBGALOI@SPH#XXXX, March 15, 
1974, Revised July 31, 1974. (SECRET) 
Contains the system test specification for 
testing the Perimeter Acquisition Radar 
and the Missile Defense Center operating 


in a netted mode and in the Accidental 
Launch defense mode. 


59. SAFEGUARD System — System Test Specifi- 


cation Grand Forks Pindown Defense 
Mode/Minuteman Defense Mode System 
Test (U) (80/035), J. F. Dorsch, Bell 
Laboratories, SIBGPM02@SP##XXXX, 
May 1, 1973, Revised May 13, 1975. 
(SECRET) 

Contains the system test specification for 
testing the Perimeter Acquisition Radar, 
the Missile Defense Center, and the Bal- 
listic Missile Defense Center operating in 
a netted mode and in the Pindown defense 


mode followed by a switch to the Minute- 
man defense mode. ‘ 


60. SAFEGUARD System — System Test Speci- 


fication Grand Forks Accidental Launch 
Defense Mode/Minuteman Defense Mode 
System Test (GF SYS/AM3) (U) (80/025), 
M. J. Suralik and R. R. Desiardins, Bell 
Laboratories, SIBGAM02@SP##XXXX, 
11277144, March 15, 1974, Revised 

May 9, 1975. (SECRET) 

Contains the system test specification for 
testing the Perimeter Acquisition Radar, 
the Missile Defense Center, and the Bal- 
listic Missile Defense Center operating in 
a netted mode and in the Accidental Launch 


defense mode followed by a switch to the 
Minuteman defense mode. 


61. SAFEGUARD System — System Test Specifi- 


cation Grand Forks Autonomous Missile 
Site Radar (MSR) Minuteman Defense Mode 
Test (U) (53/0560), J. F. Dorsch, Bell 
Laboratories, SIBGMA01SP##XXXxX, 
11277141, November 1, 1974, Revised 
December 16, 1974. (SECRET) 

Contains the system test specification for 
testing the Grand Forks configured Mis~ 


Sile Site Radar (MSR) site operating auton- 
omously in the Minuteman defense mode. 


62. SAFEGUARD System — Grand Forks Effec- 


tiveness Sensitivity to MSR and PAR Site 
Availability /Reliability Product (U) — 
Case 27950-1600, D. C. Swanay, Bell 
Laboratories MFF, February 1, 1973. 
(SECRET) 

Presents updated calculations of 
SAFEGUARD System effectiveness sensi- 
tivity to MSR and PAR site Availability/ 
Reliability (A/R) product. These calcula- 


tions include the impace of SALT deploy- 
ment limitations and reflect current sys- 


tem firing doctrine. The calculations were 


made in support of a recommendation on a 
deferred maintenance manning concept 
proposed for Grand Forks. 


63. Evaluation of System A/R — Case 36294-11, 


K. Grace, Jr., Bell Laboratories MFF, 
November 8, 1971. 


Presents an evaluation of System Avail- 
ability /Reliability through a series of 
formulas and a block diagram. The aim 
of System A/R is to make possible the 
successful completion of a mission of 
duration T, based on the probability that 
the system is operational through the 
duration of the mission. 


64. Simulation Model for System Availability — 


Case 27703-1600, T. A. Solomita, Jr. 
and K. Grace, Jr., Bell Laboratories 
TM, MM-69-8223-5, October 23, 1969. 


Describes a SIMSCRIPT simulation model 
for determining the availability of a com- 
plex-system by simulating the failure of 
on-line and spare units, and location, 
removal, repair, and replacement of 
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failed units. Includes flowcharts and de- 
scriptions of the event routines and sub- 
routines, and an example to illustrate the 
detailed output gathered from a sample 
run. 


65. SAFEGUARD System — Post-IOC Operation 


and Maintenance Study Programs (Mini- 
CTM) — Case 27950-1500, D. R. Vogel, 
Bell Laboratories MFF, October 1, 1974. 
(UNCLASSIFIED) 


Presents a plan for the evaluation of post- 
IOC operation and maintenance. 


66. SAFEGUARD — BMDC System Status Dis- 


plays — Functional Design Require- 
ments — Case 27950-1500, D. R. West, 
Bell Laboratories MFF, October 27, 1971. 


Defines the tactical display functional 
requirements for the Ballistic Missile 
Defense Center System Status Displays. 
Discusses display-panel locations, 
indicators, and functions. 


SAFEGUARD System for Control of Nuclear 


Employment Authority (U) ~ Case 27950- 
2110, N. Ehrlich, Bell Laboratories 
MFF, May 31, 1973. (SECRET) 


Describes the system for transmitting and 
receiving Nuclear Employment Authority 
(NEA) messages for SAFEGUARD. In- 
cludes the controls, displays, and system 
operation required for both the tactical 
and test modes. 


68. SAFEGUARD System — MSR and PAR 


Equipment Readiness Center and PAR 
Equipment Readiness Officer — Man/ 
Machine Description — Case 27950-2110, 
I. A. Kronish, Bell Laboratories MFF, 


November 30, 1972. 


Presents descriptions of the most recent 
design configurations of the MSR and PAR 
Equipment Readiness Centers and the 
PAR Equipment Readiness Officer work 
position. This material replaces three 
sections of thé Man/Machine Interface 
Description. 





oT 


Readiness Officer — Man/Machine 

7 Description Section 3.4, 1 — Case 27950- 
2110, T. B. Henry, Bell Laboratories 
MFF, January 11, 1973. 


me Describes the Equipment Readiness Offi- 
: cer (ERO) position in the Missile Direc- 
é tion Center. Presents a detailed console 


; description for the System Maintenance 
= console (ERO's console), the functions of 
: the cathode-ray tube and teletypewriter 


by the ERO. (The primary function of the 

ERO, on-line maintenance, is referred 
ro to elsewhere as the Site Maintenance 
Coordination Function. ) 


70. SAFEGUARD System ~— DPS Real Time Exer- 
cisers — Case 27950-1500, G. D. Kepley, 
Bell Laboratories MFF, January 27, 1970. 


Defines the type of real-time exercisers 
required for the Data Processing Subsys- 
tem, and indicates their detection capa- 
bilities, as proposed implementation, 
and an error response philosophy. 
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69. SAFEGUARD System — MSR Equipment 71. 


facilities, and specific tasks performed 72, 


SAFEGUARD System — Installation Test 
Program (ITP) Descriptions — Case 
27950-1500, L. Lesser, Bell Labora- 
tories MFF, August 11, 1972. 


Contains a description of all Installation 
Test Programs for the Madison Tactical 
Software Control Site (TSCS) to aid 
operating and maintenance engineers in 
problem solving. 


SAFEGUARD — A System Analysis of Tac- 
tical Mode Debugging Tools — Case 
27950-1500, L. J. Gawron, Bell Labora- 
tories MFF, April 1, 1974. 


Presents an analysis of a number of 
tactical mode debugging tools and pro- 
poses a package of several such tools 

for implementation within the Tactical 
Operating System. The analysis involved 
a survey of test personnel at all three 
SAFEGUARD sites (MSR, PAR, and 
BMDC), as well as at the TSCS, to de- 
termine which debugging tools would be 
most useful. 
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1. SAFEGUARD System — Data Processing 
_ System Performance Requirements, MSR 


Weapons Process (MW1) MSR System Ex- 
erciser Process (EMX) (U), 112'77024- 
Parts 1 and2, Bell Laboratories, 
SRDMSRWP@PR#H#IXXXX, June 15, 1970, 
Revised May 20, 1975 (Part 1), April 7, 
1975 (Part 2). (SECRET-RD) 


Contains the Data Processing System 
Performance Requirements (DPSPRs) for 
the Missile Direction Center (MDC) 
SPARTAN/SPRINT site in the single-site 
deployment of the SAFEGUARD System, 
consisting of the Grand Forks Perimeter 
Acquisition Radar (PAR), Grand Forks 
Missile Site Radar (MSRJ, and Ballistic 
Missile Defense Center (BMDC) in 
Cheyenne Mountain. 


2. SAFEGUARD System — Data Processing Sys- 


tem Performance Requirements, PAR 
Weapons Process (PW1) PAR System Ex- 
erciser Process (EPX) (U), 11277025, 

Bell Laboratories SRDPARWP@PR##XXXX, 
June 15, 1970, Revised May 20, 1975. 
(SECRET) 

Contains the DPSPRs for the PAR Data 
Processor in the single-site deployment 


of the SAFEGUARD System, consisting of 
the PAR, the MSR, and the BMDC. 


3. TACSAF Users Guide (U), J. Golub, Gen- 


eral Research Corporation, Internal 
Memorandum DIM #332, November 15, 
1974.-- (SECRET) 

Describes the SAFEGUARD Simulation, 


its capabilities and limitations, and the 
options available to the user. | 
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References for Chapter 5 


SAFEGUARD System Evaluation 


4. MSRSIM Users Guide, Internal Memorandum 


DIM #333, John T. Fyfe, General Research 
Corporation, November 13, 1974. 
Describes the MSR Simulation, its capa- 


bilities and limitations, and the options 
available to the user. 


5. Intercept Subsystem Evaluation Phase I (U), 


Vol I-Il, McDonnell-Douglas Astronautics 
Company, Report No. MDC G1246, 
November 1969. (SECRET-RD) 


Contains an evaluation of SPRINT intercept 
capability; an analytical determination of 
miss distance and applicable regions of the 
field of fire; and an evaluation of the effects 
of warhead and RF shadowing on kill prob- 
ability, and the utility of intercept-point 
bias and drag-bias guidance techniques. 


6. Intercept Subsystem Evaluation Phase II (U), 


Vol I-II, McDonnell-Douglas Astronautics 
Company, Report No. MDC G1379, 
August 1970. (SECRET-RD) 


Describes the development of the non-real- 
time version of the SPRINT Engagement 
Simulation (SES) and Monte Carlo simula- 
tion of 80 intercept points over the field 

of fire to verify analytic results. 


7. Intercept Subsystem Evaluation — Phase II 


(U), Vol I-Il, McDonnell-Douglas Astro- 
nautics Company, Report No. MDC G1952, 
July 1971. (SECRET-RD) 


Describes the determination of guidance~ 
critical intercepts for specifying Meck 
Test Program requirements, the evalua- 
tion of the effect of reduced missile and 
target-track rates on intercept effective- 
ness, the evaluation of the real-time tar- 
get-prediction algorithm, and the develop- 
ment of linear-intercept effects models 
for system simulation. 


8. Intercept Subsystem Evaluation, Phase IV 


(U), McDonnell-Douglas Astronautics 
Company, Report No. MDC G3719, 
August 1972. (SECRET) 


Contains the effects of target wake on 

SPRINT intercept effectiveness, the in- 
vestigation of exoatmospheric RV tumble 13 
on beta history during early reentry, and 

the initial evaluation of real-time guidance 
algorithms. 


9. Intercept Subsystem Evaluation, Phase V 


(U), Vol I and Il, McDonnell-Douglas 
Astronautics Company, Report No. MDC 
G4774, July 1973. (SECRET) 


Contains the evaluation of the real-time 
guidance algorithms and their effective- 
ness in the waking-target environment, 
and the effect of target misidentification 
on intercept capability. 


Describes the program of SPARTAN 
intercept tests conducted at Meck to vali- 
date the SPARTAN Intercept Simulation 
(SPASIM). Also indicates the overall ap- 
proach to simulation validation, the rea- 
sons for selecting the particular tests, 
and the test results. 


. SENTINEL System — System Development 


Plan, Vol IV — System Evaluation Pro- 
gram (U), Bell Laboratories, Report 
69RO19, March 1969. (SECRET) 


Presents the results of early evaluation 
studies on PAR performance, specifically 
the probability of detection and perform- 
ance of the nonuniform track scheme. 
Describes the initial simulations devel- 
oped for system evaluation, including a 
SPARTAN footprint generator. Also con- id 
tains the initial set of test requirements kes 
developed for the Meck Test Program. 


14. SAFEGUARD System — System Development 


10. Intercept Subsystem Evaluation, Phase VI 


(U), MceDonnell-Douglas Astronautics 
Company, Report No. MDC G5347, 
March 1974. (SECRET) 


Contains the characterization of miss dis- 
tance and intercept-point (IP) motion 

over the SPRINT field of fire, the deter- 
mination of the linear region applicable 

to the tactical design, and the updating 

of the miss distance and IP motion models 
for the system simulation. 


11. SPRINT Intercept Subsystem Validation — 
Final Summary Report (U), Vol I-HL, 15. 


McDonnell-Douglas Astronautics Company, 
Report No. MDC G5355, March 1974. 
(SECRET) 


Describes the program of SPRINT inter- 
cept tests conducted at Meck to validate 
the SPRINT Intercept Simulation (SIS) . 
Also indicates the overall approach to 
simulation validation, the reasons for 
selecting the particular tests, and the 
test results. 


12, SPARTAN Intercept Subsystem Validation 


and.Characterization — Final Summary 
Report (U), McDonnell-Douglas Astro- 
nautics Company, Report No. MDC G5336, 
March 1974. (SECRET) 
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Plan, Vol 3 Parts I-III — System Evalua- 
tion Program (U), Bell Laboratories, 
March 1970. (SECRET-RD) 


Presents the system evaluation results 
for 1969. Includes the MSR and PAR per- 
formance studies, the SPRINT and 
SPARTAN capability studies, and the per- 
formance of the battle-planning functions 
in the nuclear environment, Part III is 
devoted to simulation development and 
modeling for SAFSIM, MSRSIM, and the 
SPRINT and SPARTAN Intercept Simula- 
tions. 


SAFEGUARD System — System Development 


Plan, Vol 3, Books 1-3 — System Evalua- 
tion Program (U), Bell Laboratories, 
March 1971. (SECRET-RD) | 


Presents the system evaluation results 
for 1970. Major activities included 
threat-evaluation system effectiveness 
versus offensive strategies and MSR/ 
MSDP traffic-capacity studies. Also con- 
tains additional modeling information for 
SAFSIM and MSRSIM, updated test re- 
quirements and data analysis plans for 
the Meck Test Program, and results of 
the initial tests at Meck. 


s 


© 16. SAFEGUARD System — System Development 
Plan, Vol 3, Books I-III — System Evalua- 
ae tion Program (U), Bell Laboratories, 
March 1972. (SECRET-RD) 


Presents the system evaluation results 
for 1971. Major activities included MSR/ 
MSDP and PAR/PARDP traffic-capacity 
and overload-response studies, the en- 
vironmental effects on SPRINT intercept 
capability, and initial studies of MSR 

gic track.in the cluttered environment. Also 
includes Meck Test Program results and 
evaluation test plans for TSCS and the 
tactical site. 


17. SAFEGUARD System — System Development 
Plan, Vol 3 — System Evaluation Program 
(U), Summary Report and Appendices 





ES 
(4 books), Bell Laboratories, March 1973. 
(SECRET-RD) 

eo Presents the system evaluation results 


for 1972. Includes evaluation of MSR 
track in the cluttered environment (wake 
and tank breakup), PAR track of unre- 
solved targets, SPRINT effective field of 


go fire, SPARTAN effectiveness, traffic- 

; capacity and overload studies, and system 

oe 8 false alarm rates. Also includes Meck 
Test Program results and simulation 
development, 

$e 18. SAFEGUARD System — System Development 


Plan, Vol 3 — System Evaluation Pro- 
gram, Part 1, MSR Functional Perform- 
ance (U), Bell Laboratories, January 
1975. (SECRET) 


pest 


Summarizes MSR/MSDP performance in 
the functional areas of surveillance, track, 
target selection, and SPRINT and 
SPARTAN intercept performance. In- 
cludes coast cluster track, wake track, 
tank breakup, and nuclear effects. 


(ares 





19, SAFEGUARD System — Analysis of Controlled 
Test Requirements (U), Bell Laboratories, 
May 1, 1970. (SECRET) 


& 
i 
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eestor, 


SPRY 


Contains a detailed discussion of the im- 
portance of maintaining control over the 
extraneous debris that normally accom- 
panies target complexes so that data- 
gathering objectives can be more easily 
satisfied. 


20. SAFEGUARD System — Revised Natural 


Breakup Model for Titan II Tank (U), Bell 
Laboratories, Report 73R126, September 
1973. (SECRET) 

Describes a natural breakup model for a 
Titan II tank for use by SAFEGUARD de- 


signers to evaluate the impact of this en- 
vironment on system performance, 


21. SAFEGUARD System — Tank Breakup — The 


Phenomenology of Contiguous Clutter 
(Titan IT) (U), Bell Laboratories, Report 
73R130, September 1973. (SECRET) 
Reviews aspects of the Titan II tank break- 


up phenomenon relevant to understanding 
the contiguous~clutter effect. 


22. SAFEGUARD System — Wake Track Functional 
_ Evaluation Report — Missions in the R19 


Test Period (U), Calspan Corporation, 
Report No. UB-2946-S-35, January 1974. 
(SECRET) 


Analyzes the performance of the wake- 
track algorithms during five Meck track- 
ing missions. Includes results using tar- 
gets on both radial and offset trajectories, 
performance of wake-track entrance and 
exit tests, and measurement accuracies 
(biases and measurement variance). 


23. SAFEGUARD System — Track Through Tank 


Breakup Functional Evaluation Report (U), 
Calspan Corporation, Report No. UB- 
2946-S-52, October 1974, (SECRET) 


Analyzes the performance of the track- 
through-tank-breakup algorithms during 
six Meck tracking missions. Two prob- 
lems noted during analysis of early mis- 
sions were investigated; solutions were 
found, implemented, and checked out on 
later missions. 


24, SAFEGUARD System — Modeling of Radar 
Signal Returns From Wake Based on MSR 
M2/R17-R19 Data (U), Calspan Corpora- 
tion, Report No, UB-2946-S-43, March 
1974. (SECRET) 

Documents wake models derived from in- 
dividual pulse profiles (digital video re- 
corder data) of wakes recorded by the 
Meck MSR. Presents a detailed descrip- 
tion of the rigorous statistical techniques 


used to.derive the models. The models 
described were incorporated in MSRSIM. 


25. SAFEGUARD System — Wake Track Func- 

' tional Evaluation Report — Missions in the 
R19E and R20 Test Periods (U), Calspan 
Corporation, Report No. UB-2946-S-48, 
September 1974. (SECRET) 

Analyzes the performance of the wake- 
track algorithms during six Meck tracking 
missions in the R19E-R20 time frame. 
Extends the analysis to include targets on 
fly-by trajectories. Includes an evalua- 


tion of changes made in the wake-track 
algorithms. 


26. SAFEGUARD System — Meck Test Require- 
ments for SAFEGUARD System Evaluation 
(U), Bell Laboratories, June 1, 1968, 
Revised May 1, 1972. (SECRET) 
Details requirements for all tests con- 
ducted at Meck to evaluate the system, in- 
cluding radar function test requirements 
and SPRINT and SPARTAN interceptor 


test requirements. Also details the data 
to be obtained on each of these tests. 


27, SAFEGUARD System — Meck Test System 
Compared with the System to be Deployed 
Case 27950-1500, L. Bernstein, Bell 
Laboratories MFF, October 19, 1971. 
Contains a broad description of hardware 
and software differences between the 


Meck and Grand Forks SAFEGUARD 
installations. 


28. SAFEGUARD System — SPARTAN Intercept 
Function — M2/Tactical Differences 
Case 27950-1600, E. D. Ballard, Jr., 
Bell Laboratories MFF, March 9, 1973. 


IV-30 


Contains a description of the differences 
in implementing the SPARTAN intercept 
function at the Meck and Grand Forks 
SAFEGUARD installations. 


29. SAFEGUARD — Comparison of Tactical and 
M2 System Data Gathering Algorithms - 
Case 27950-1600 (U), M. E. Jacobs and 
R. A. Steigerwalt, Bell Laboratories 
MFF, January 3, 1973. (SECRET) 
Contains a description of the differences 


between the Meck and Grand Forks imple- 
mentation of the data-gathering algorithm. 


30. SAFEGUARD System — Differences Between 
the Tactical and Meck Versions of the 
SPRINT Intercept Function — Case 27950- 
1600, W. P. Chapman, Bell Laboratories 
MFF, April 19, 1973. 


Contains a description of differences be- 
tween Meck and Grand Forks implemen- 
tation of the SPRINT intercept function. 


31. SAFEGUARD System — System Development 


Plan, Vol 1 — Meck Island System De- 
scription (U), Bell Laboratories, Revised 
April 1973. (SECRET) 


Contains information concerning the 
SAFEGUARD System research and de- 
velopment equipment installed in the 
Kwajalein Atoll, including a compre- 
hensive description of the subsystem 
and range instrumentation. 


32, SAFEGUARD System — Summary of MSR 
Data Analysis — M1 Test Period (U), 
Cornell Aeronautical Laboratory, Report 
No. UB-2946-S-11, March 1972, 
(SECRET) 


Summarizes the analysis of MSR perform- 
ance based on data gathered during the 
M-1 test period at Meck. Includes data 
handling, bias analysis, single-pulse 
range and angle accuracy, analysis of 
track-filter performance, amplitude 
measurement accuracy, and RCS meas- 
urement analysis. 
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33. SAFEGUARD System — M-2 System Func- 
tional Requirements and Description (U), 
Bell-Laboratories, August 1, 1972. 
Revised August 1, 1973. (SECRET) 
Compiles the M-2 revision level R20 of 
the Meck software and includes a broad 


description of functional capabilities re- 
quired for R20 and prior revision levels. 


34, SAFEGUARD System — Meck System Test 
Program (U), Bell Laboratories, June 1, 
1970, Revised February 28, 1974. 
(SECRET) 
Contains information concerning the Meck 


Island research and development test pro- 
gram in support ofthe overall SAFEGUARD 


System evaluation program, including mis- 


sion descriptions for all planned system 
tests, 


35. SAFEGUARD System — Target Support Plan 
(U), Bell Laboratories, June 15, 1970, 
Revised January 15, 1974. (SECRET) 


Contains information on the ICBM and 
IRBM targets used at Meck, such as pro- 
curement cycle, design requirements, de- 
scription of Reentry Vehicles (RVs), auxil- 
iary objects, target delivery systems, and 
broad target-related mission results. 


36. SAFEGUARD System — Summary of Docu- 
mentation Available for Meck System 
Evaluation Tests, S. F. Knakkergaard, 
Bell Laboratories MFF, May 16, 1975. 


Contains a mission-by-mission tabulation 
of major premission and post-mission 
reports for the M-1 and M-2 periods. 
The following reports are included in the 
tabulation: 


Mission Test Specification defines the 
mission objectives and requirements, 
and includes range instrumentation 
priority assignments. 

Mission Test Plan restates mission ob- 
jectives and requirements, and speci- 


fies operational details for conducting 
a mission. 


Final Mission Test Report provides final 


critique on data qualification and pre- 
sents data in a large number of plots. 
Data analysis is not included. 


Target Data Summary summarizes the 
results of MSR data relating to the 
target delivery system performance. 


Mission Data Summary Memorandum pre- 
sents MSR data in a series of plots to 
be used as a tool for mission analysis 
and function evaluation. 


Preliminary Mission Test Specification 


was used prior to 1972 to present an 
early representation of mission ob- 
jectives and requirements. 


Mission Data Analysis Summary Report 


summarizes results of primary analy- 
sis of MSR performance. 


This memorandum also lists documents 
related to miss distance measurement data. 


37. SAFEGUARD System — Summary of Meck 


MSR Measurement Performance Analysis 
(U), D. R. Johnson and R. A. VanSlooten, 
Calspan Corporation, Report No. UB- 

2946-S-42, February 1, 1974. (SECRET) 


Summarizes MSR measurement perform- 
ance, Includes analysis of results on 
frequency-dependent range biases (TRM- 
87), T3/T1 range biases (TRM-113), 
amplitude-dependent angle biases (TRM- 
113), target-track/missile-track biases 
(TRM-112), off-axis angle accuracy (TRM- 
98), and face-to-face biases (TRM-95). 


38. SAFEGUARD System — Independent Miss 
Distance Measurement in the Meck Test 
Program (U), Bell Laboratories, Report 
71R074-10, June 1971. (SECRET) 


Discusses the various method considered 
for measuring miss distance on SPRINT 
and SPARTAN live-target intercept mis- 
sions. Provides the rationale and 
justification for the recommended 
measurement technique. 


39. SAFEGUARD System — System Integration 
and Evaluation Test Plan (U), Bell Labo- 
ratories, July 1973. (SECRET) 


Contains a detailed description of the 
system test and evaluation program 
originally planned for SAFEGUARD. 
Describes the philosophy and approach 
taken in developing the program and the 
rationale for each of the test scenarios. 


40. SAFEGUARD System — System Integration 
and Evaluation Test Plan Revision (U), 
Bell Laboratories, G-741752, Revised 
July 1974. (SECRET) 
Provides the same information as for the 
original program plan but for a test pro- 
gram that was reduced in scope. This 


was the program conducted for the 
SAFEGUARD System. 


41, TACSAF Analysis of the M1/M3 (DPM) 
Scenario (U), General Research Corpora- 
tion, Internal Memorandum DIM #324, 
July 26, 1974, (SECRET) 


Documents the results obtained with the 


system simulation for one of the five Sys- 


tem Technical Verification Test (STVT) 
scenarios. (Also see References 42 
through 45.) This scenario tested the 
Grand Forks configured MSR site opera- 
ting autonomously in the Minuteman De- 
fense Mode. The results of testing under 
all five scenarios provided the basis for 
the performance criteria contained in the 
test specifications. The scenario is de- 
scribed and the nominal system response 
to the scenario is provided. Variations in 
functional performance (i.e., detection 
altitudes, RV call altitudes, etc.) ob- 
served in a series of Monte Carlo runs 
are indicated. Variations in total system 
response due to relatively low probability 
occurrences are described and the proba- 


bility of observing that particular response 


is estimated. 


42, TACSAF Analysis of the SYS/A3 Scenario 
(U), General Research Corporation, 
Internal Memorandum DIM #321, 

May 17, 1974, (SECRET) 
Documents the results obtained with the 
system simulation for the netted PAR, 


MSR, and BMDC operating in the Acci- 
dental Launch Defense Mode. ; 


43. TACSAF Analysis of the SYS/M3 Scenario 
(U), General Research Corporation, 
Internal Memorandum DIM #325, 
August 8, 1974. (SECRET) 

Documents the results obtained with the 
system simulation for the netted PAR, 


MSR, and BMDC operating in the Minute- 
man Defense Mode. 
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TACSAF Analysis of the SYS/AM3 Scenario 
(U), General Research Corporation, 
Internal Memorandum DIM #327, 
September 30, 1974. (SECRET) 


44, 


Documents the resulis obtained with the 
system simulation for the netted PAR, 
MSR, and BMDC operating in the Acci- 
dental Launch Defense Mode followed by 
a switch to the Minuteman Defense Mode. 


45. TACSAF Analysis of the SYS/PM3 Scenario 
(U), General Research Corporation, 
Internal Memorandum DIM #326, 
September 10, 1974. (SECRET) 
Documents the results obtained with the 
system simulation for the netted PAR, 
MSR, and BMDC operating in the Pindown 
Defense Mode followed by a switch to the 
Minuteman Defense Mode. 


46. SAFEGUARD System — System Test Specifi- 
cation, Grand Forks Autonomous MSR 
Minuteman Defense Mode Test (DPM)(U), 
(5410100) 11277146, J. F. Dorsch, Bell 
Laboratories, SIBGMA02@SP##XXXX, 
March 15, 1974, Revised June 10, 1974. 
(SECRET) 

Contains the System Test Specification 
(STS) for testing the Grand Forks config- 
ured MSR site operating autonomously in 
the Minuteman Defense Mode. Provides 
a detailed description of the scenario, to- 
gether with the particular performance 
criteria applicable to the test. Includes 
the performance bounds and the proced- 
ures to be used for verifying the system 


performance. (Also see References 47 
through 50. ) 


47, SAFEGUARD System — System Test Specifi- 
cation, Grand Forks Accidental Launch 
Defense Mode System Test (U), (80/010) 
11277142, M. J. Suralik, Bell Labora- 
tories, SIBGALO2@SP##XXXX, February 
11, 1974, Revised April 15, 1975. 
(SECRET) 

Contains the STS for the netted PAR, 


MSR, and BMDC operating in the Acci- 
dental Launch Defense Mode. 


ee 48, SAFEGUARD System — System Test Specifi- 
: cation, Grand Forks Minuteman Defense 
Mode System Test (SYS/M3) (U) (80/015), 
M. J. Suralik, Bell Laboratories, 
SIBGMM03@SP##XXXX, March 15, 1974, 
Revised October 30, 1974, (SECRET) 
Contains the STS for the netted PAR, 


MSR, and BMDC opérating in the Minute- 
man Defense Mode. 


49. SAFEGUARD System — System Test Specifi- 
cation, Grand Forks Accidental Launch 
Defense Mode/Minuteman Defense Mode 
System Test (GF SYS/AM3) (U), (80/025) 

' 11277144, M. J. Suralik, Bell Labora- 
tories, SIBGAM02@SP##XXXxX, March 15, 
1974, Revised December 15, 1974. 
(SECRET) 


Koeenay 


Beers 
te ; 


BRT ENT 
: ! 


ENR 


iter. 


Sre~ ss: 
oe 


rent 


IV-33 


Preps 
vitae tae 


freon 
be * 


50. 


Contains the STS for the netted PAR, 
MSR, and BMDC operating in the Acci- 
dental Launch Defense Mode followed by 
a switch to the Minuteman Defense Mode. 


SAFEGUARD System — System Test Specifi- 


cation, Grand Forks Pindown Defense 
Mode/Minuteman Defense Mode System 
Test (U), (80/035) 11277145, J. F. Dorsch, 
Bell Laboratories, SIBGPM02@SP##XXXX, 
May 1, 1973, Revised August 23, 1974. 
(SECRET) 

Contains the STS for the netted PAR, 

MSR, and BMDC operating in the Pindown 


Defense Mode followed by a switch to the 
Minuteman Defense Mode. 
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References for Chapter 6 


Nuclear Vulnerability and Hardening 


1, SAFEGUARD System Special Environmental Summarizes results of the SAFCA EMP 
Criteria, 11425709 (U), Revision B, Cl eee ern 
Bell Laboratories, February 5, 1973. of EMP on SAFEGUARD communications 
(SECRET-RD) circuits. 
Specifies the nuclear environments for 5. SAFEGUARD System — Missile Site Radar 


SAFEGUARD ground equipment. 
(MSR) Subsystem Hardware Assessment 


Report (U), Final Issue, Bell Labora- 


Nuclear Requirements, 11327052 (U), tories, May 1, 1975. (SECRET) 


Revision A, Bell Laboratories, October Reports results of MSR nuclear hardness 
16, 1974. (SECRET-RD-CNWDI) assessment. 
Specifies the nuclear environments for the 6. SAFEGUARD System — Perimeter Ac- 


SPRINT missile in flight. 
quisition Radar (PAR) Subsystem Hard- 


3. SAFEGUARD System — SPARTAN In- Flight ness Assessment Report (U), Final 


Nuclear Environments, 11327051 (U), Issue, Bell Laboratories, January 15, 
Revision A, Bell Laboratories, October 1975. (CONFIDENTIAL) 


16, 1974, (SECRET-RD-CNWDI) Reports results of PAR nuclear hardness 
assessment, 
Specifies the nuclear environments for 
the SPARTAN missile in flight. 
7. SAFEGUARD System — Data Processing 
System (DPS) Hardness Assessment Re- 
port (U), Final Issue, Bell Laboratories, 


May 1, 1975. (CONFIDENTIAL) 


4, Effects of EMP on Bell System Long Haul 
Transmission Facilities, I, G, Durand, 
D. V. Batorsky, L. Coffey, R. L. 


Johnson, G. F. Raupp, and P. M. Reports results of DPS nuclear hardness 
Simonelli, Bell Laboratories, April 30, aneecnment. 
1974. 
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8, SAFEGUARD System — Common Equipment 


Hardness Assessment Report (U), Final 
Issue, Bell Laboratories, May 1, 1975. 
(CONFIDENTIAL) 

‘Reports results of nuclear hardness 


assessment of equipment common to more 
than one SAFEGUARD subsystem. 


9. SAFEGUARD System — Summary Hardness 


Assessment Report: Electromagnetic 
Pulse and Miscellaneous Nuclear Effects 
(U), Bell Laboratories, May 1, 1975. 
(SECRET) 


Reports results of EMP hardness 
assessment for SAFEGUARD ground-based 
facilities. Also reviews criteria develop- 
ment and summarizes subsystem hardness 
assessments for aerial dust, crater 

ejecta impacts, debris, and blast/ground 
motion-induced building rotations. 


10. SAFEGUARD System — SPRINT Missile 


Subsystem Final Hardness Assessment 
Report (U), Bell Laboratories, January 
15, 1975, (SECRET) 


IV-36 


Reports results of SPRINT Subsystem 
nuclear hardness assessment. 


11. SAFEGUARD System ~ SPARTAN Missile 


Subsystem Final Hardness Assessment 
Report (U), Bell Laboratories, February 
15, 1975. (SECRET) 


Reports results of SPARTAN Subsystem 
nuclear hardness assessment. 


12, SAFEGUARD System — Lessons Learned in 


the SAFEGUARD Nuclear Vulnerability 
and Hardening Program, Bell Labora- 
tories, June 1, 1975. 


Points out lessons learned — both mana- 
gerial and technical — by Bell Labora- 
tories and its subcontractors during the 
SAFEGUARD Nuclear Vulnerability and 
Hardening Program, 
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1. The Missile Site Radar (U), R. C. Newhouse; 


and Technical Characteristics of the 
Missile Site Radar (U), P. L. Hammann, 
— Case 27703-1400, Bell Laboratories, 
May 19, 1964. (SECRET) 


Transcript of presentations on the Missile 
Site Radar (MSR) as conceived at the time 
of presentation, May 19, 1964. Summa- 
rizes the initial MSR system concept and 
details of the technical characteristics 

of the initial MSR design. 


2. Work Statement for Development of the Mis- 


sile Site Radar, GA-8532 Revision E, 
Bell Laboratories Report, May 6, 1964, 
Revised October 1, 1968. (SECRET) 


Establishes requirements for the work to 
be done in connection with the develop- 
ment of the prototype MSR installed at 
Meck Island, This work statement was a 
part of Bell Laboratories Contract 600630 
with the Raytheon Company. 


3. NIKE-X Redundancy Analysis — Case 27703- 


1600 (U), M. T. Fine, Bell Laboratories 
MFF, December 21, 1966. 
(CONFIDENTIAL) 


IV-37 


References for Chapter 7 


Missile Site Radar . 


Presents the results of a study which 
shows the effect of NIKE-X subsystem 
availability and reliability on subsystem 
cost, considering redundancy. For pur- 
poses of this study, the missile site 
module, which includes the Missile Site 
Radar (MSR) and the Missile Site Data 
Processor (MSDP), was selected. 


4. SAFEGUARD System — Final Report of 


MSR Hardware Tests at Meck Island — 
Case 27703-1710 (U), G. A. Ripsom, 
Bell Laboratories MFF, August 30, 
1969. (SECRET) 

Covers MSR testing at Meck from the 
initial start date of February 1, to 
August 1, 1968 to the requirements of 


the GA-8532 Work Statement, Revision E, 
dated October 1, 1968. 


. NIKE-X Weapon System, Missile Site Radar 


Description (U), Bell Laboratories, 
April 1, 1967. (SECRET) 


Provides a brief description of the func- 
tions and characteristics of the MSR and 
its major subsystems, Covers operating 
frequencies; waveforms transmitted and 
received; digital, transmitter, receiver, 
and antenna major assemblies. Pri- 
marily describes the Meck prototype MSR 
and has not been updated to the tactical 
design. 


6. Work Statement Specification for the Develop- 
ment (Phase IV) of the Tactical Missile 
Site Radar (MSR) SAFEGUARD System 
(U), GA-8601 Revision C, Bell Labora- 
tories, May 24, 1968, Revised November 
1, 1972. (SECRET) 

Establishes the design objectives for the 
MSR and defines the work to be performed 
in adapting the prototype design, as de- 
fined in GA-8532, for use in the tactical 
SAFEGUARD System. This work state- 


ment was a part of Bell Laboratories Con- 
tract 601873 with the Raytheon Company. 


7, IMSR Hardware Development and Installation 
Schedules — Case 27703-1400, P. L. 
Hammann, Bell Laboratories MFF, 
January 28, 1970. 

Summarizes the development and installa- 


tion schedule and incremental hardware 
cost for the IMSR radar modification. 


8. SAFEGUARD System — Tactical System In- 
terface Missile Site Radar Operational 
Description (U), G-634441, Bell Labora- 
tories, January 1, 1971, (SECRET) 
Contains information on the general char- 


acteristics of the radar and on how each 
subsystem performs. 


9. SAFEGUARD System — MSR Hardness 
Status — Report of Hardness Review at 
Raytheon, October 7-8, 1969 — Cases 
27703-2130 and 27703-1400, P. B. 
Grimado and L. A. Peralta, Bell Labora- 
tories MFF, December 4, 1969. 
Comments on the October 1969 review of 
the program to harden the Missile Site 


Radar equipment against shock and vi- 
bration (principally nuclear), 


10. SAFEGUARD System — Missile Site Radar 
(MSR) Subsystem Hardness Assessment 
Report (U), Bell Laboratories, Final 
Issue October 15, 1974. (SECRET) 


Final summary Hardness Assessment 
report for the Missile Site Radar, in- 
cluding exposed and housed equipment. 


11, Crater Ejecta Threat to Faces of 
SAFEGUARD MSR Building — Case 
27950-2130 (U), J. M. Jacisin, Bell 
Laboratories MFF, June 25, 1973. 
(SECRET) 

Assesses the severity of the crater 
ejecta environment on the element faces 
- of the SAFEGUARD Missile Site Radar 


building for a specified peak overpres- 
sure, 


12, SAFEGUARD System — Review of MSR An- 
tenna Service Vehicle — Case 27950-2110, 
H. W. Lubow and J. G. Trautman, Bell 
Laboratories MFF, July 19, 1973. 
Documents the results of a review of the 
MSR Antenna Service Vehicle held at 
Bell Laboratories, Whippany, N.J., in- 


cluding such aspects as safety, human 
factors, and corrosion control. 


13. NIKE-X MSR — Antenna Performance with 
Large Numbers of Failed Elements — 
Case 27703-1400, T. H. Feiertag, Bell 
Laboratories MFF, May 6, 1966. 


Discusses curves of root-mean-square 
(rms) sidelobe degradation, gain loss, 
and rms Steering error for the MSR when 
0 to 50 percent of the front radiating 
elements are made inoperative, 


14. SAFEGUARD — The System Impact of MSR 
Q-Channel Blanking Performance (U) — 
Case 27950-1600, W. F. Boyer, Bell 
Laboratories MFF, April 15, 1974, 
(SECRET) 


Documents a study conducted to determine 
the system performance implications of 
the current estimate of Q-channel blank- 
ing performance. Concludes that this 
current Q-channel performance does not 
Significantly degrade the overall system 
and recommends a revision of the MSR 
Performance Design Specification. 
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15. NIKE-X — MSR Q-Channel Performance — 
Case 27703-1400 (U), S. B. Windes, 
Bell Laboratories MFF, July 8, 1966. 
(SECRET) 
Defines the MSR Q (broadbeam receiving) — 
channel and investigates its effectiveness 


in helping to prevent sidelobe tracking 
with and without a clutter fence. 


16. SAFEGUARD System MSR — Q-Channel 
Evaluation ~ Case 27950-1400, P. D. 
Hansell, Bell Laboratories MFF, 
December 13, 1973. 

- Outlines a procedure for determining 
MSR Q-channel receiver parameters using 
only the receiver. The purpose of this 
procedure is to measure the effect of 
these parameters on Q~channel blanking 
performance and to define a range of 


values for which performance meets or 
exceeds specified values. 


17. SAFEGUARD System — MSR - Prototype and 
Tactical Phase Shifter Diode Reliability — 
Case 27950-1400, M. R. Dungan, Bell 
Laboratories MFF, March 18, 1971. 
Records a presentation covering prototype 
(Meck) diode failures and rates, acceler- 
ated aging test and effectiveness, evalua- 
tion of the tactical diode reliability, and 


predicted tactical system phase shifter 
failure rates, 


18. A High Power, S-band, Reciprocal, PIN 
Diode Phase Shifter — Case 27703-1400, 
G. C, Di Piazza and R. J. Gutmann, 
Bell Laboratories TM, MM-65-6468-1, 
August 21, 1965. 
Describes design details of diode phase 
shifter built for initial MSR design. 
Present MSR phase shifter design was 
based on work reported here, extrapo- 


lated to the higher power requirements 
of the prototype and tactical systems. 


19. Diode Specification for High Power Micro- 
wave Phase Shifters and Switches — 
Cases 27703-1950 and 27703-1800, 
A. Zacharias, Bell Laboratories TM, 
MM-67-2652-5, March 9, 1967. 


Explores the interaction between circuit 
parameters and diode parameters in 
high-power microwave phase shifters 
and switches, and presents a design 
procedure for producing a shifter or 
switch that is optimum for a given 
application. 


20. NIKE-X MSR — Relation Between Phase 


Shifter Bit Size Error and Antenna 
Performance — Case 27703-1400, S. B. 
Windes, Bell Laboratories MFF, 
September 21, 1966, 

Documents a computer-aided study to 
determine how MSR antenna perform- 
ance would be affected by uncertainties 


in determining the average size of the 
phase shifter control bits. 


21. NIKE-X MSR Antenna Performance vs. 


Number of Phase Shifter Bits — Case 
27703-1400, R. J. Tromley, Bell Lab- 


oratories MFF, April 22, 1966. 


(CONFIDENTIAL) 


Summarizes calculated MSR antenna 
performance as a function of the number 
of phase shifter bits. The data include 
effects of antenna random errors which 
result from manufacturing tolerances, 
reflections, and calibration inaccuracy. 


22. NIKE-X MSR — Proposed Methods of Antenna 
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Per-Element Phase Alignment — Case 
27703-1400 (U), P. T. Sproul, Bell 
Laboratories MFF, March 20, 1964. 
(CON FIDENTIAL) 

Describes the phase shifter bit measure- 
ment system and estimates accuracy of 


measurement, Discusses implementa- 
tion for fault location use. 


» SAFEGUARD — MSR — Use of RF Absorber 


on Small Array Adapter Ring — Case 
27703-1400 (U), S. B. Windes, Bell 
Laboratories MFF, January 15, 1970. 
(CONFIDENTIAL) 


Presents reasons for recommending that 
absorber material be added to the adapter 


ring around the Missile Site Radar array, 
Signal-to-clutter ratios that meet system 
requirements are among the objectives of 
this recommendation. 


24, SAFEGUARD System — MSR Antenna Retro- 
fit for Absorbing Spill-over Energy — 
Case 27703-1400, D. L. Chandler, Bell 
Laboratories MFF, June 9, 1970, 
Describes the methods of retrofit pos- 
sible when adding an absorber to attenu- 
ate the feedhorn spillover energy on the 


RF chamber front-end adapter of the 
Missile Site Radar. 


25, SAFEGUARD System — MSR Array Sur- 
veys — Case 27950-1400, D. L. 
Chandler, Bell Laboratories MFF, 
August 24, 1971. 

Presents detailed optical methods for 
determining the effective pointing direc- 
tion and clocking angle of each tactical 
MSR array. Includes a method to relate 
these parameters to system coordinates, 


The optical techniques apply equally to 
Meck and tactical arrays, 


26, SAFEGUARD System — Missile Site Radar 
Monopulse Comparator Alignment — 
Case 27950-1400, E. O. Martin, Bell 
Laboratories MFF, January 3, 1974. 
Details a simple and effective technique 
for monopulse comparator alignment on 


the Meck Missile Site Radar. This tech- 
nique was used successfully at the Grand 


28. SAFEGUARD — Dispersed Pulse Amplitude 


Measurement and Adaptive Thresholding 
for the Tactical MSR (Summary) (U) — 
Case 27950-1400, P. D. Hansell and 

K, M. Hueter, Bell Laboratories MFF, 
June 27, 1972. (CONFIDENTIAL) 
Discusses design concept of dispersed 
pulse measurement, which will provide 


improved tracking of waking targets and 
improved AGC operation. 


29. NIKE-X Missile Site Radar — Low Level 


Transmitter Configuration, J. H. 
Pruden, Bell Laboratories MFF, 
March 8, 1965. 


Describes the planned MSR low-level 
transmitter configuration and its con- 
nections to other MSR equipment, and 
describes a suggested revision. Com- 
pares the two configurations and presents 
objections and a possible compromise 

to the revision, 


30. Missile Site Radar (MSR) Command, Control, 


and Interface Computer (CCIC) — Func- 
tional Description (MSR 4. 1-11), Raytheon 
Company, Revision 1, July 31, 1969. 


Describes how various digital radar- 
controlled transform computers gener- 
ated orders as timing pulses for analog 
radar equipment and how replies based 
on these orders are generated for pro- 
cessing by the computer. 


Forks MSR. 31. SAFEGUARD System — MSR Transmitter ~ 


27, SAFEGUARD System — MSR — Tactical RF 
Receiver Compression Performance — 
Case 27950-1400, E. W. Potter, Jr., 
Bell Laboratories MFF, September 29, 
1971. 
Briefly describes the main difference be- 


tween the tactical MSR RF receiver and the 
prototype designs. Includes a block dia- 


gram description of the tactical RF re- 32. 


ceiver and plots of the compression curves 
and input/output measurement curves for 
the double conversion mixer, the UHF 
Mixer/IF amplifier, and the three-stage 
parametric amplifier stages of the tactical 
design. 
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Summary of VA-144 Performance — 
Case 27950-1400, P. T. Sproul, Bell 
Laboratories MFF, December 27, 1974. 


Summarizes performance of the VA-144 
klystrons at Meck and at Grand Forks. 
Includes discussion of problems en- 
countered and solutions achieved. Also 
considers life experience at Meck versus 
design goal. 


VA -144 ESM RB-9 Program, Vol I-VI, 


Varian Associates. 


Documents all work performed in final 
development of the VA-144 kiystrons 
for tactical MSR transmitter. Includes 
copies of key technical memoranda. 


33, Waveguide Breakdown Effects at High Average 
Power and Long Pulse Length, A.S. 

S Acampora and P. T. Sproul, BSTJ, 

Vol 51, No. 9, November 1972. 

Discusses waveguide breakdown due to 

particulate matter in the presence of 

long pulses and high average power and 

develops an analytical solution to pre- 


dict breakdown performance. Confirming 
experimental results are presented. 


34, SAFEGUARD System — MSR — Feedhorn 
and Waveguide Arc Logic — Case 27950- 
f 1400, J. H. Pruden, Bell Laboratories 
: MFF, August 3, 1971. 


Reviews logic associated with recent 


e findings concerning the mechanisms of 
bos waveguide and feedhorn arcing in the MSR 
bo. to ascertain that the corrective and pro- 


tective actions taken in the high level 
transmitter are optimum to maintain 
MSR operation. 
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35. SAFEGUARD System — MSR Grand Forks 
Collector Pressure Increase Problem 
Summary — Case 27950-1400, P. T. 
Sproul, Bell Laboratories MFF, March 
20, 1975. 

is Summarizes the effort to identify the 

source of a pressure drop increase in the 

klystron cooling channel. The problem 
was encountered only at the Grand Forks 


2 installation. Includes the results of the 
ea study and corrective action. 


36. NIKE-X Missile Site Radar Interface with 
in Input/Output Controller of the Data | 
Processing System — Case 27703-1400, 
J. O. Hardy, Bell Laboratories MFF, 
December 13, 1965. 


PRES 


parersapy 
Weck. 


ge Documents information on the interface 

i between the Input/Output Controller of 

I the NIKE-X Data Processing System 

ee and the Missiles Site Radar Command, 
Control, and Interface Computer. 


37. SAFEGUARD System — Tactical System Inter- 


face — Missile Site Radar/Data Processor 
ge (U); Digital Data Format Specifications, 
F G-438801, Bell Laboratories, 
& 


KMFTSIMD@FS##XXXX, October 1, 1969, 
Revised February 3, 1975. (SECRET) 


CEE 
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Contains information on the various 
instructions and interfaces, with the 
parameter contained in the interface 
words identified as to value and limits. 


SAFEGUARD System — MSR/MSDP Inter- 


faces, Vol Il — Hardware/Software 
Interactions (U), Books 1 and 2, 
G-741636, Bell Laboratories, June 1, 
1973, (SECRET) 

Contains information on the data paths 
selected in the MSR based on the trans- 


mit and receive instructions and what in- 
formation is generated as radar replies. 


SAFEGUARD System — MSR/MSDP Inter- 


faces, Vol I -- Timing and Control (U), 
Part 1, G-741636, Bell Laboratories, 
August 31, 1973. (CONFIDENTIAL) 


Contains information necessary to deter- 
mine what timing operations occur within 
the Missile Site Radar as a result of a 
radar transmit or receive instructions in 
all modes of operation, 


Missile Site Radar (MSR) Beam Steering 


Computer (BSC) Functional Description, 
(BAA 4, 2-11), Raytheon Company, 
September 15, 1967, 

Describes the process of converting 
sing and sing steering angles to phase 


differences between adjacent radiating 
elements, 


Digital Control Group Concept Document, 


Vol I-IV, L. Shear, Raytheon Company, 
BR-7579, November 1973. 


Contains information on the design con- 
cepts and descriptions of the various 
digital controllers that interface with 
the analog sections of the MSR. 


42, SAFEGUARD System — MSR Radar Monitor 


Console Displays and Interfaces — Case 
27950-1400, G. T. Kresan and R. H. 
Thieme, Bell Laboratories MFF, 
December 21, 1971, 


44. SAFEGUARD System — Study of MSR Digital 


Describes all Radar Monitor Console 
(RMC) indicators, controls, and inter- 
faces. 


43. NIKE-X MSR — Outline of Required Internal 


Radar Tests — Case 27703-1400, R. A. 

Reed, Bell Laboratories MFF, January 

* 20, 1966. 

Outlines those MSR tests requiring more 
than one subsystem and varying degrees 


of control by the MSDP. Establishes 
overall requirements for these tests, 


Control Group (DCG) Diagnostic Test 

for Fault Location — Case 27950-1400, 
L. R. Hamilton, Bell Laboratories MFF, 
December 9, 1971. 

Describes the results of a study of the 
controller located in the control rack to 
determine the feasibility of using the 


test outputs for fault isolation and main- 
tenance purposes in the DCG, 


47. MSR Stateside Antenna Subsystem Test 


Report (U), Raytheon Company, BR-4644, 
August 1, 1968, with Errata Sheet, 
December 23, 1968. (SECRET) 

Peritains to measurements of a full-scale 


MSR antenna array on a pattern measure- 
ment range. 


Part 1 — Data summary by performance 
areas, specifications, and 
design objectives. 


Part 2 — Appendix A: Antenna Patterns 
Part 3 — Appendix B: Contour Plots 


48, SAFEGUARD System Reliability Program 


Review, April 5 and 6, 1972, Minutes, 
Bell Laboratories, April 1972. 
(SECRET) 


A review and update of the current A/R 
values for the SAFEGUARD System and 
its major equipment based on currently 
available data reflecting the Phase I de- 
ployment concept. 


49. NIKE-X — MSR Antenna — Characteristics 


45. System Development Plan, Vol 3 — System 


Evaluation Program, Part 1 — MSR 
Functional Performance (U), Bell Labora- 
tories, January 1975, (SECRET) 
Contains all significant evaluation results 
for the tactical MSR and Missile Systems, 
Includes the Calspan analyses of sphere 


and satellite tracking data showing range 
and angle tracking accuracies. 


SAFEGUARD Performance/Design Specifica- 
tion Missile Site Radar (U), 11327054 
Revision B, Bell Laboratories, October 
16, 1974, (SECRET) 

Specifies the performance and design 
characteristics of the MSR to establish a 
production base, This specification is 


the highest generation document covering 
the MSR. 
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of EMP Considered as Threat to MSR — 
Case 27703-1400 (U), T. H. Feiertag, 
Bell Laboratories MFF, September 29, 
1966. (SECRET) 

Calculates the spectrum and energy 
content of a typical Electromagnetic 
Pulse (EMP) caused by a nuclear detona- 


tion to determine its effect on the MSR 
antenna front element and phase shifter. 


50. NIKE-~X — MSR Antenna — EMP Threat to 


MSR Antenna — Case 27703-1400 (U), 
S. E. Windes, Bell Laboratories MFF, 
August 25, 1967. (SECRET) 

Updates a previous memorandum by 

T. H. Feiertag, dated 9/29/66, en- 


titled, “Characteristics of EMP Con- 
sidered as a Threat to MSR." 
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1. PAR Phase IA Report (U), General Electric 


Company, EHM-11043, March 1, 1967. 
(SECRET) 


Summarizes the initial definition phase of 
the Perimeter Acquisition Radar (PAR) 
development. Includes detailed require- 
ments and configuration for the PAR. 


14, 
PAR Phase II Definite Plans (U), Revision A, 


Vol I-X, General Electric Company, 
EHM-1134/75, Revised May 1968. (Vol 
_1-V, VIL, and IX — SECRET; Vol VI, VIH, 
and X — UNCLASSIFIED). 


Volume I Executive Summary 15. 


Volume II Technical Development 
Plan 


Volume III Specifications, Books 1-10 
Volume IV. Program Operations Plan 
Volume V Manufacturing Plan 
Volume VI Site Activation Plan 
Volume VIL Test Plan 


Volume VII Configuration Management 
Plan 


Volume IX __ Reliability and Quality 
Assurance Plan 


Volume X Engineering Support Plans 
Summarizes the development of the PAR, 


including the design, development, and 
manufacture of the PAR equipment. 


17. 
12. SAFEGUARD System — Technical Require- 


ments for Facilities Construction, Vol 1 

and 3, Issue 2, Rev 2C, J. G. Matthews, 

Bell_Laboratories, November 16, 1972. 
Volume 1 General, Drawing Nos. 


11277040, 11277041, and 
11277042, Issue 2, Rev 2C. 
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16. 


References for Chapter 8 


Perimeter Acquisition Radar 


Volume 3 PAR Building, Drawing Nos. 
11277048, 11277049, 
11277040. 


Contains detailed drawings of the PAR 
facilities to be constructed in North 
Dakota (PAR-1) and Montana (PAR-2). 


SAFEGUARD System — PAR-1 R&D Test 


Plan, Revision A, Bell Laboratories, 
August 2, 1972. 
Defines the test program to verify system 


performance for the PAR installation at 
Grand Forks, North Dakota, 


SAFEGUARD System — Special Environmen- 


tal Criteria, Bell Laboratories, 11425709 
Revision B, August 18, 1971. (SECRET) 
Defines the environmental criteria the 


radar equipment had to meet to withstand 
nuclear effects. . 


Analysis of the Beam Steering Errors Arising 


from Antenna Element Displacements of a 
Phased Array Radar, D. J. Enright, Bell 
Laboratories TM, TM-75-6512-1, 

April 10, 1975. 

Analyzes beam steering errors caused by 


mechanical displacements of the antenna 
elements. 


SAFEGUARD System — PAR — PAR Spec- 


trum Signature Summary Report (U) — 
Case 27950-1940, V.-D. Vanacore, Bell 
Laboratories MFF, March 26, 1975. 
(SECRET) 

Summarizes the characterization of the 


PAR spectrum signature, including 
electromagnetic compatibility. 


18. SAFEGUARD Performance/Design Specifica- 


tion Perimeter Acquisition Radar (U), 
BMDMP 4.04. A, 11327060, Revision B, 
Bell Laboratories, November 21, 1969, 
Revised October 16, 1974. (SECRET) 


Contains the radar subsystem perform- 
ance requirements for the PAR. 


19, SAFEGUARD System — Perimeter Acquisi- 


tion Radar (PAR) Subsystem Hardness 


Assessment Report (U), Case 27950-2130, 
Bell Laboratories, Final issue, January 


15, 1975. (CONFIDENTIAL) 
Summarizes the program to evaluate the 


ability of the hardware to withstand the 
nuclear shock andvibration requirements. 


20. SAFEGUARD System — An Analysis of the 


Effect of Thermal Noise on the PAR Angle 
Tracking Precision (U) — Case 27950~ 
1940, D. J. Enright, Bell Laboratories 
MFF, December 18, 1972. (SECRET) 
Analyzes the effect of thermal noise on 


the PAR angle tracking precision, in- 
cluding expected PAR performance. 


21. SAFEGUARD System — PAR External Re- 


ceive Pattern Measurements Program — 
Final Report (U), A. T. Vitenas, Bell 
Laboratories MFF, July 26, 1974. 

' (SECRET) 
Describes a program to measure the an- 


tenna receive pattern. Includes an analy- 
sis of the measurement results. . 


22. NIKE-X PAR Trade-off and Study Report (U), 


Volume I-XIV, General Electric Company, 
July 1, 1967, (SECRET) 
Volume I Cost Optimization Study 
Volume II Transmitter Study 


Volume Il Antenna and RF Component 
Study 


Volume IV Signal Processing Synthesis 
Volume V-_ Monitoring Study 


Volume VI Environment and Propaga- 
tion Studies 
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Volume VII Radiation Control Study 
Volume VII Specifications — Tube 


Volume IX Specifications — Solid 
State 


Volume X Surveillance Performance 
Studies . 


Volume XI Noise Measurement and 
Threshold Determination 
Studies 


Volume XII Parametric Studies 


Volume XHI Availability vs Cost 
Analysis 


Volume XIV Cost and Schedule Study 


Discusses the results of a study concern- 
ing system design problems, schedules, 
cost, and trade-offs for a PAR program 
evolving from the NIKE-X system. In- 
cludes the rationale for component selec- 
tion and specifications for equipment to 
be used in the PAR. : 


. Analysis of Auroral Data from Prince Albert 


Radar Laboratory, Final Report, W. E. 
Jaye, W. G. Chestnut, and B. Craig, 
Stanford Research Institute, SRI Project 
7465, September 1969. 

Summarizes the results of a study con- 
ducted at Prince Albert Radar Laboratory 


in Canada to investigate auroral effects 
at UHF. 


37. SAFEGUARD System — Description of the 


Hardness Verification Program for the 
PAR Ground Plane and Antenna Elements ~ 
Case 27950-2130, L. ¥Y. Cooper, Bell 
Laboratories MFF, January 20, 1971. 


Describes a program to evaluate the PAR 
facility and equipment for hardening 
against nuclear shock and vibration, 
thermal stress, dust, and debris to en- 
sure that PAR integrity could be main-~ 
tained during an attack. 


PAR Sensor Subsystem — Availability and 


Reliability Summary (U), General Elec- 
tric Company, October 24, 1973. 
(CONFIDENTIAL) 


Discusses the availability and reliability 
of components in the PAR. 





1, SAFEGUARD System — SPRINT Warhead 
s Section Tests.— Case 27950-1000, D. B. 
: Seamans, Bell Laboratories MFF, 
October 28, 1971. 
Summarizes the results of SPRINT War- 
head Section tests to date, including re- 
sults of both the preflight ground testing 


of the FTQs (Flight Test Qualification 
ee Units) as well as flight tests, 





ie 2. SAFEGUARD SPRINT Interceptor Response — 

4 Intercept Deadzone (U) — Case 27703- 

: 1500, S. C. Nordberg, Bell Laboratories 
MFF, March 26, 1970. (CONFIDENTIAL) 


Describes a method developed to deter- 
mine the upper and lower limits of the 
missile capability deadzone along the tra- 
jectory of a particular object. Assumes 
that missile capability bias is available, 
and shows how a two-iteration process 

é is used to compensate for approxima- 

i, tions of missile and target flight. Accu- 
racy of the method is well within the 
limits required by SPRINT Interceptor 
Response for intercept planning. 


3. SAFEGUARD Performance/Design Specifica- 
tion SPRINT Subsystem (U), 11327045 
Rev. A, Bell Laboratories, December 
31, 1969, Revised December 18, 1974, 
ue (SECRET) 





4. SPRINT Phase II Development Program 
e- Summary, Martin Marietta Corporation, 
OR-3650-1, February 1973. (SECRET) 


Accents the highlights of the development 
© program. 
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Peery 


References for Chapter 9 


SPRINT Missile Subsystem 


5. Phase Il Development Plan SPRINT Subsys- 


tem (U), Vol I-IV, Martin Marietta 
Corporation, OR-3650-2, July 1974. 


Volume I — System Description and 
Overall Development Plan. 
Gives an overall descrip- 
tion of SPRINT, including 
major changes that have 
occurred, (SECRET) 


Volume II ~ Engineering Development 
and Test Programs, Gives 
a complete description of 
the development and testing 
of major assemblies. In- 
cluded are some problems 
encountered and their res- 
olutions. (SECRET-RD) 


Volume III — Support Activities. Gives 
a description of support 
activities such as pro- 
gramming, quality, relia- 
bility, procurement and 
documentation. 
(CONFIDENTIAL) 


Volume IV — Flight Test Program. In- 
Cludes a listing of the 
flight test program with 
Significant milestones high- 
lighted. (SECRET) 


6. SAFEGUARD System — Missile Subsystem 


Interface Description (U), Bell Labora- 
tories, January 1, 1974. (SECRET) 


Combines remote launch design require- 
ments with all hardware and software 
interfaces, except Guidance, which is 
covered below (Reference 7). 


7. SPRINT I Missile Subsystem Interface Speci- 
fication — Guidance Software withSPRINT 
I Missile Hardware (U), 11268700, Bell 
Laboratories, November 27, 1973. 
(SECRET) 


8. SPRINT — S-Band Attenuation Measurements 
on SPRINT 1si and 2nd Stage Motors 
(U) ~ Case 27703-1000, E. P. Chowaniec 
and L. L. LeBlanc, Bell Laboratories 
MFF, February 3, 1965. 
(CONFIDENTIAL) 
Presents results, methods, and corre- 
lation for RF attenuation measurements 
performed on SPRINT first- and second~ 
stage motors at the Allegheny Ballistics 
Laboratory. .These measurements were 
part of the SPRINT communications pro- 
gram designed to achieve the first slant- 


look measurements at S-band through 
full-scale flame plumes. 


9. SAFEGUARD SPRINT/SPARTAN Component 
Parts, First Source Status Program 
(G741194) —~ Cases 27703-1000 and 


27703-1010, J. Brown, Bell Laboratories 


MFF, April 28, 1969. 


Discusses the program written to list 
the SPRINT/SPARTAN Component part 
"first source" information. Lists the 
functions of the program and indicates 
the key-punching formats. 


10. SAFEGUARD System — First Stage Ballistic 
Trajectories for Remote Launch of the 
SPRINT Missile — Case 27703-1000, 

R. H. Whiting, Bell Laboratories MFF, 
May 12, 1969. 

Derives the algorithm and justifies the 
assumptions used to calculate trajec- 


tories for SPRINT after first-stage burn- 
out with delayed second-stage ignition. 


11. SAFEGUARD System — SPRINT Missile Sub- 
system ~— Final Hardness Assessment 
Report (U), Bell Laboratories, 
January 15, 1975. (SECRET-RD) 


12, A Reliability Model for the SPRINT Missile — 
Case 27703-1600(U), S. Dier, Bell Labo- 
ratories MFF, June 30, 1967. (SECRET) 
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Generates and makes available probabil- 
istic data and analysis pertinent tc. the 
development of a reliability model of the 
SPRINT missile. 


18. SAFEGUARD Performance/Design Specifi- 
cation — SPRINT Control Equipment 
(Remote) (U), 11327050 Rev. A, Bell 
Laboratories, May 26, 1970, Revised 
October 16, 1974. (SECRET) 


14, SPRINT Interceptor Response — Location 
of SPRINT Missile Blackout — Case 
27950-1500 (U), R. L. Buchwalter, Bell 
Laboratories MFF, December 10, 1970. 
(CONFIDENTIAL) 
Describes an analytical method for loca- 
ting blackout along the SPRINT trajec- 
tory. The method considers the charac- 
teristics of the SPRINT trajectory, the 


blackout volume, and the times of for- 
mation and dissipation of the fireball, 


15, Final Report ~— Aging and Deterioration 

Test Program — First and Second Stage 
Rocket Motors, Martin Marietta Corp- 
oration, Document No. TRP 10301481- 
008, June 27, 1975. (UNCLASSIFIED) 
Presents the results of tests on SPRINT 
missile motors aged in a configuration 
and environment simulating the tactical 
in-cell conditions. Discusses motor 


design, propellant, test configuration, 
and test procedures, 


16. SAFEGUARD Performance/Design Specifi- 
cation — SPRINT Launch Equipment (U), 
11327047 Rev. A, Bell Laboratories, 
October 16, 1974, (SECRET) 


17. SPRINT Test Control and Monitoring Unit 
. (MGS Testing), S. Gross, Bell Labora- 
tories TM, MM-67-6223-3, May 17, 
1967. 


Describes the operation and circuit 
structure of the SPRINT Test Control 
and Monitoring Unit, which is being 
used for automatic, long-term relia- 
bility testing of the SPRINT Missile 
Guidance Set. 
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18. Shock Testing of SPRINT Missile Guidance 
Sets and Safety and Arming Devices in 
Simulated Flight Environments — Cases 
27703-1000 and 25601, A. F. Stormont, 
Bell Laboratories MFF, March 20, 1969. 
Reviews test criteria; describes test appa- 
ratus, instrumentation and data analysis 
methods; and compares flight-produced 
and laboratory-simulated shock environ- 


ments in the guidance, control, and war- 
head compartments of the SPRINT missile. 


19. SAFEGUARD System — SPRINT Burst Delay 
Timer: Effectiveness Study (U) — Case 
27703-1600, M. J. DeFazio, Bell Labora- 
tories MFF, June 23, 1969. (SECRET-RD) 
Describes a study made to determine the 
conditions, if any, under which a SPRINT 
Burst Delay Timer would be useful for 
enhancing the effectiveness of the 
SAFEGUARD System. Includes consider- 


ation of SPRINT self-blackout and effects 
of ionizing radiation. 


20. Accleration and Acoustic Testing of SPRINT/ 
SPARTAN Cables and Antennas — Cases 
27703-1000, 27703-1010 and 37994-2, 

R. T. Wood, Jr., Bell Laboratories 

MFF, September 8, 1969. 

Records results of acoustic noise and 
acceleration tests made on SPRINT/ 


SPARTAN cables 11276263, 11275280, 
and 11275152, 


21. SAFEGUARD System — SPRINT — Effects of 
Launch Station Verticality and Azimuth 
Errors on the Pitchover Error Budget 
(U) — Case 27950-1000, E. F. Engelbert, 
Bell Laboratories MFF, February 14, 
1972, (CONFIDENTIAL) 

Make a determination as to the extent of 
station verticality and azimuth errors on 


the overall pitchover error budget for the 
SPRINT missile system. 


22. Recommendations for Harnessing Techniques 
for SPRINT — Cases 37992-1 and 27703- 
1810, G. J. DeVries, Bell Laboratories 
MFF, July 29, 1968. 


Discusses a lecture-demonstration on the 
preparation of wiring harnesses for the 
SPRINT missile. Shows the advantages 
of different processing techniques, includ- 
ing the use of flat wireboards, master 
template breakouts, precut wires, and 
preterminated shields. 


23. SPRINT MBGE Test Set Encoder Section — 
Case 36294-22, L. Rosa, Bell Labora- 
tories MFF, May 22, 1964. 


Reports results of Bell Laboratories re- 
liability analysis of the memory system 
contained in the encoder section of the 
SPRINT Missile-Borne Guidance Equip- 
ment test set. Mean time between replace- 
ments figures for the memory system, the 
encoder less the memory, and the encoder 
with the memory are included. 


24, Calibration of SPRINT Autopilot Acceler- 
- ometer (U) — Case 27703-1810, H. J. 
Luer and R. G, McCoy, Bell Laboratories 
MFF, July 20, 1964. (CONFIDENTIAL) 


Describes statistical analysis undertaken 
in setting performance parameter limits 
for the SPRINT autopilot accelerometer. 
Discusses nature of SPRINT missile error 
budget and the application of the Central 
Limit Theorem in the statistical approach 
to the calibration of the autopilot acceler- 
ometer. Tabulates maximum errors 
allowable in accelerometer calibration. 


25. SPRINT/SPARTAN — Reliability Study of 
MGS R&D Field Experience — Case 
36294-22, W. J. Akstulewicz, Bell 
Laboratories MFF, September 29, 1969. 
Documents a reliability study of Missile 
Guidance Sets under research and devel- 
opment field conditions. The study con- 
sidered (1) units in ground test programs, 


(2) those sets designated for flight tests, 
and (3) sets in storage. 


26. SPRINT Missile Guidance Set, Reliability 
Evaluation Results — Case 36294-22, 
Richard G. Smith II, Bell Laboratories 
MFF, September 11, 1970. 

Describes implementation of the test pro- 
gram defined in SPRINT Guidance Set 


Reliability Evaluation Specification 
G485090 and documents the test results. 
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28, SENTINEL System — Explosive Quantity — 33 


27, SPRINT — Launch Preparation Equipment — 32. 


Case 36294-22, T. L, Tanner, Bell 
Laboratories MFF, March 26, 1971. 


Reviews the reliability predictions for the 
integrated-circuit version of the SPRINT 
Launch Sequencer (IC LSEQ), which re- 
places the discrete LSEQ in the Launch 
Preparation Equipment for the tactical 
SPRINT system. 


Safety Distances for SPARTAN and 
SPRINT Missiles — Case 27703-2110, 
C. G. Reinschmidt, Bell Laboratories 
MFF, September 4, 1968. 


Documents a reduction in the distances 
required between quantities of SPRINT 
and SPARTAN missiles and the nearest 
inhabited building. The revised safety 
classification should permit easier han- 
dling and controlling of missile sections 
during checkout. 


34, 
29. SAFEGUARD System — SPRINT EED No-fire 


Characteristics — Case 27950-1000, 
J. A. Freund, Bell Laboratories MFF, 
June 25, 1971. 


Describes tests of SPRINT missile 
Electro-Explosive Devices (EEDs) to de- 
termine input power levels induced in the 
devices by several types of electromag- . 
netic fields. 


35. 
30. SAFEGUARD System — Missile Subsystem 


Safety Interlocks — Case 27950-1000, 

D. P. Worrall, Bell Laboratories MFF, 
February 4, 1974. 

Reviews the utilization of safety interlocks 
and Safety Interlock Override in the mis- 


sile subsystems and the remote launch 
equipment. 


31, NIKE-X — Acquisition of a SPRINT Missile 


in the Toss-and-Catch Mode — Case 
27703-1600 (U), W. P. Chapman, Jr., 
Bell Laboratories MFF, February 28, 
1967, (CONFIDENTIAL) 

Reviews the problem of establishing track 
on a SPRINT missile after it is launched 


from a site several miles from the track- 
ing radar, c 
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36. 


SAFEGUARD System — SPRINT PACA Safety 
Margins (U) ~ Case 27950-1000, J. A, 
Freund, Bell Laboratories MFF, 

July 20, 1972, (SECRET) 

Analyzes safety margins for various 
electromagnetic radiation environments 
during transportation of the SPRINT mis- 


sile Propulsion and Control Assembly 
(PACA). , 


. SENTINEL System — SPRINT — Proposed 


UTL Testing Program — Case 27703- 
1000, J. R. DeTizio, Bell Laboratories 
MFF, March 18, 1969. 


Proposes a test program for the two 
SPRINT/SPARTAN Universal Transporter 
Loader (UTL) prototypes. The test pro- 
gram is composed of (1) Design Develop- 
ment Testing, (2) Acceptance Testing, 

{3} Design Verification Testing, and 

4) Qualification Testing. 


NIKE-X — Factor of Safety, Proof Testing 
and Recertification Testing — Case 
27703-1600, C. G. Reinschmidt, Bell 
Laboratories MFF, June 29, 1967. 
Clarifies the use of safety factors in the 
design of NIKE-X equipment and the re- 


quirements for proof testing and recerti- 
fication of handling equipment before use. 


SAFEGUARD Performance/Design Specifi- 
cation — SPRINT Air Vehicle (U), 
11327046 Rev. A, Bell Laboratories, 
January 7, 1970, Revised December 18, 
1974, (SECRET) 


SENTINEL System — Flame Propagation 
Tests on Hydraulic Fluids — Case 
27703-2110, J. A. Wojciak, Bell 
Laboratories MFF, January 23, 1969. 


Describes procedures and results of 
flame propagation tests performed on 
five hydraulic fluids. Based on results 
of these tests, recommends the use of 
fire resistant fluids in new hydraulic 
system designs rather than the currently 
used petroleum based fluids or enclosure 
of hydraulic lines to eliminate the pos- 
eibtity of spraying oil from a ruptured 
ine. 











37. Environmental Requirements for the SPRINT 


Subsystem (U), Specification MO-141H, 
Martin Marietta Corporation, September 
15, 1971. (SECRET) 


38. SAFEGUARD System — SPRINT — Autopilot 


Timer_Error Study — Case 27950-1000, 
R. C. McCrea, Bell Laboratories MFF, 
August 19, 1970. 

Presents the results of a study into the 


effects of early "time-out" of the timing 
circuit on SPRINT initial pitchover angle, 


39. "Space Phase Lag" and SPRINT Steering 


Order Resolving Schemes (U) — Case 
27703-1000, G. J. Ryva and J. C. Hsu, 
Bell Laboratories TM, MM-65-4264-6 
and 65-4232-11, May 20, 1965. 
(CONFIDENTIAL) 


Seeks to clarify the deleterious effects of 
SPRINT ''space phase lag" (the continual 
error between the spacial orientations of 
the commanded and achieved lateral 
accelerations when the missile rolls). 
Compares the three-resolver scheme 
currently used for SPRINT to the more 
common one-resolver scheme regarding 
effectiveness in reducing space phase lag. 


40. Preliminary Study of Blackout Effects on 


SPRINT Miss Distance (U) — Case 27703- 
1600, F. J. Hinger, Bell Laboratories 
MFF, July 5, 1967. (SECRET) 


Presents the results of a preliminary 
study of the effects of blackout on SPRINT 
guidance. The results were obtained by 
Monte Carlo methods applied to a two- 
dimensional simulation of a SPRINT 
guidance package. 


41, Simulation of SPRINT Launch Eject High- 


Frequency High-Level Shock Environ- 
ments — Cases 25601 and 27703-1000, 


P. Johansen, Bell Laboratories MFF, 
June 28, 1967. 


Summarizes alternative methods available 
for simulating the SPRINT Missile-Borne 
Guidance Equipment and Autopilot shock 
environments, and presents results of a 
laboratory evaluation of a ballistie pendu- 
lum method. 


42, SPRINT Launch and Test Planning Feasi- 


bility Study of SPRINT Launch Recovery 
System, D. Lomax, Bell Laboratories 
MFF, September 9, 1964. 


Presents a Martin Company mathematical 
simulation of the loading dynamics of the 
Shock Recovery System used for SPRINT 
launch eject tests, summarizing the ana- 
lytical method used. 


43. Deriving Body Attitude from SPRINT Flight 
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Data ~ Case 27703-1000, B. D. Jensen, 
Bell Laboratories TM, MM-66-6481-3, 
December 15, 1966. 


Shows how the complete dynamic history 
of a missile flight can be determined if 
the acceleration vector is given in both 
the missile and battery coordinate sys- 
tems and the angular rate about one of 
the missile axes is known. 


44. An Investigation of Staging Transients on 


SPRINT WSMR Flights 7 and 8 ~ Case 
27703-1000 (U), W. P. Wesley, Bell 
Laboratories MFF, July 5, 1967. 
(SECRET) 


Presents the result of an investigation to 
determine the nature and origin of previ- 
ously unexpected forces acting on the 
SPRINT missile during separation from 
the first stage. The Simulated Analog 
Missile, a full 3-dimensional analog sim- 
ulation of the SPRINT missile which con- 
tains a detailed program of the missile 
functions and nominal missile aerody- 
namics, was used in the investigation. 
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1, SAFEGUARD Performance/Design Specifi- 


cations, Bell Laboratories, 


SPARTAN Subsystem, 11327041 Rev A, 
December 18, 1974, (SECRET) 


SPARTAN Air Vehicle, 11327042 Rev A, 
December 18, 1974. (SECRET) 


SPARTAN Launch Equipment, 11327043, 
August 12, 1970, (SECRET) 


SPARTAN Ground Support Equipment, 
11327047, December 1974. 


Provide performance requirements and 
design specifications. Also establish a 
base for tactical production drawings and 
associated test and logistics support 
requirements. 


2, SAFEGUARD System — SPARTAN Subsys- 


tem — Development Plan (U), Vol I—I, 
McDonnell -Douglas Astronautics Company, 
January 31, 1966, Revised August 1972, 
(SECRET) 


Summarizes the design and planning effort. 


Descriptions of the role of SPARTAN in 
the SAFEGUARD System, missile con- 
figuration, site facilities, and program 
schedules (including yearly milestone and 
flight test schedules) are presented. Also 
included are program plans and schedules 
for engineering, ground testing, flight 
testing, manufacturing, quality control, 
reliability, logistics, procurement, 
documentation, facilities, and field site 
operation, 


3. SAFEGUARD/SPARTAN Fault Tree Analysis, 


McDonnell- Douglas Astronautics Company, 
MDC G5183, June 1974. 
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References for Chapter 10 


SPARTAN Missile Subsystem 


Presents a quantitative assessment of 
inadvertent missile launch, Identifies 
components whose failure would result 
in a critical event, indicates probability 
of occurrence, and shows critical paths 
and associated failure probabilities. 


4, SAFEGUARD System — SPARTAN Missile 


Subsystem Final Hardness Assessment 
Report (U), Bell Laboratories, 
February 15, 1975. (SECRET) 

Final issue in the series of SPARTAN 
missile subsystem hardness assessment 


reports, Contains results of each pro- 
gram and lists all pertinent documentation. 


5. SPARTAN Missile Rain Erosion Test ~ Case 


27950-1000, N. R. Lampert, Bell Labo- 
ratories MFF, October 8, 1970. 


Describes the results of recalibrating the 
pressure instruments used in high-speed 
rainfield tests of a SPARTAN missile nose 
cone, 


6. SAFEGUARD System —~SPARTAN Response 


to Guidance Orders (U) - Case 27950-1010, 
J. B. McCauley, Bell Laboratories MFF, 
January 26, 1972. (CONFIDENTIAL) 
Explains briefly the nature of the 


SPARTAN missile response to a guidance 
command during second-stage flight. 


7. SENTINEL-SPARTAN Explosive Separation 


System Development and Test Results, 
McDonnell-Douglas Astronautics Company, 
DAC 58769A, September 1968. 

Describes the development, design, and 
testing of the interim design explosive 


separation system for the SPARTAN 
missile. 


8. Implementation of Loss of RF Destruct for 
SPRINT and SPARTAN — Cases 27703- 
100 and 27703-1010, J. L. Henry, Bell 
Laboratories MFF, October 15, 1969. 
Proposes a means of interfacing the Mis- 
sile Guidance Set/Warhead Adaption Kit 


missing messages which trigger missile 
safe destruct. 


9. SAFEGUARD System — SPARTAN — 
SPARTAN Third-Stage Orientation 
Accuracy (U) — Case 27950-1010, J. B. 
McCauley, Bell Laboratories MFF, 

May 10, 1972, (SECRET) 

Explains the nature and extent of aero- 
dynamic effects on the centerline orienta- 
tion of the SPARTAN third-stage vehicle 


during the final flight phase before 
intercept. 


10. Qualification Testing of the SPARTAN Safety 
and Arming Device (SAD) — Case 27950- 
1000, J. Lowe, Bell Laboratories MFF, 
April 2, 1971. 
Describes tests and results of qualification 
testing of the SPARTAN II safety and arm- 
ing device. Shock response spectrum 


graphs for the 2500 g, 0. 067-millisecond 
qualification test are shown, 


11, NIKE-X/ZEUS: Analysis of Space Phase Lag 
with a Four-Gimbal Stable Platform (U) — 
Case 27703-1010, E. J. Schuler, Bell 
Laboratories MFF, March 25, 1966. 
(CONFIDENTIAL) 
Analyzes Space Phase Lag (spatial orien- 
tation between the commanded and 
achieved lateral acceleration vectors of a 
missile in flight), considering only the ef- 
fect of missile roll. Investigates use of a 


stable four-gimbal platform for the ZEUS 
missile, 


12, NIKE-X/ZEUS — Documentation of Missile 
Acceleration and Attitude Error Analysis 
Programs for Steering Control Systems — 
Case.27703-1010, J. W. Levengood, Bell. 
Laboratories MFF, December 15, 1966. 
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Documents two digital computer programs 
for analyzing SPARTAN missile accelera- 
tion and attitude errors caused by gain and 
null errors in the SPARTAN steering con- 
trol systems, 


13. Explanation of the Stable Platform Flip Ma- 


neuver and the Laboratory Simulation of 
this Maneuver — Case 27703-1810, F. M. 
Stepniak, Bell Laboratories MFF, 

August 1, 1966. 

Explains the execution of a ''Flip"’ maneu- 
ver by the all-attitude, four-gimbal 
SPARTAN stable platform as required for 


maintaining proper reference under cer- 
tain conditions of SPARTAN flight. 


14. SAFEGUARD System — Thermal Stress Anal- 
ysis of SPARTAN Launch Area Antenna 
Window — Case 27703-1810, J. R. Mc Kay, 
Bell Laboratories MFF, July 13, 1970. 
Analyzes thermal stress during nuclear 
blast to which the SPARTAN launch area 


antenna window may be subjected and con- 
cludes that the window is unlikely to fail. 


15. SAFEGUARD System — SPRINT/SPARTAN 
Tactical Electromagnetic Radiation (EMR) 
Environment — Cases 27950-1000 and 1010 
(U), J. A. Freund, Bell Laboratories 
MFF, July 18, 1972. (SECRET) 
Documents the basis for calculating the 
tactical EMR environments produced by 
the Missile Site and Perimeter Acquisition 
Radars (MSR and PAR). A worst-case en- 
vironment is defined for the SPRINT and 
SPARTAN missiles during flight, their 
launch stations, the universal missile 


building, the warhead facility, and the 
remote SPRINT launch site. 


16. SAFEGUARD System — EMR Induced Inad- 
vertent Launch Analysis for the SPRINT 
and SPARTAN Missiles (U) — Cases 
27950-1000 and 1010, J. A. Freund, Bell 
Laboratories MFF, July 20, 1972. 
(SECRET) 

Gives safety margins for electromagnetic 
radiation induced inadvertent launch of 
SPRINT and SPARTAN missiles for in-cell 


configurations of closed cell, open cell, 
and maintenance mode, 


Ff i 17. SAFEGUARD System — SPARTAN Launch 
Cell Thermal Analysis — Case 27858- 

cr 1010, W. R. Sieling, Bell Laboratories 

; MFF, October 19, 1973. 

Discusses the possibility of SPARTAN 

motor autoignition if the SPARTAN aux- 

iliary power unit gas generator should 


fire inadvertently. Predicts the worst 
case of temperaturé environment within 


Presents an analysis to determine the dy- 
namic temperature history of a surface 
on which SPARTAN missile exhaust gases 
impinge, e.g., the deflector plate and 
junction boxes in the cell. The analysis 
was initiated in response to data which 
indicate that temperatures in the tactical 
design launch station will be considerably 
higher than those found in the old shallow- 
depth cell, 


the SPARTAN launch cell. 21, SAFEGUARD System — SPARTAN Launch Cell 


18. SAFEGUARD System — SPARTAN — Results 
of the MDAC Analysis to Determine the 
re Lock-out Requirements for the Axial 
Isolation System — Case 27950-1010, 
C. S. DeSilets, Bell Laboratories MFF, 
November 30, 1970. 
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Discusses the McDonnell-Douglas analysis 
of the dynamics of launching the SPARTAN 
missile supported by an unlocked axial 
isolation system. 


Sa 


19, SAFEGUARD System ~ SPARTAN — Response 
a of the Axial Isolation System to Earth- 


Preparation Equipment Vault (LPEV) — 
LPEV Nuclear Ground Shock Environment 
Requirements — Cases 27950-2130 and 
27950-1010, J. F. Stevenson and C, S. 
DeSilets, Bell Laboratories MFF, 
September 29, 1970. 


Outlines procedures used in establishing 
requirements for nuclear ground shock 
environmental testing. Records data on 
shock spectra envelopes and acceleration- 
time histories that are consistent with the 
shock spectra, to be used for mathemati- 
cal analysis purposes, as well as aiding 
in establishing future test criteria for 
LPEV equipment. 


quake Induced Ground Motions -- Case 22. SAFEGUARD System — SPRINT/SPARTAN 


27950-1010, C. S. DeSilets, Bell Labora- 
5 tories MFF, April 7, 1971. 


Presents an analysis of the responses of 
damped structures to earthquakes. This 
analysis was initiated because of the con- 
cern that the axial isolation system, being 
3 designed to keep the vertical acceleration 
* of the SPARTAN missile supported on its 
launch rail below 1 g during nuclear 
¢ ground shock conditions, may not be able 
to maintain the structural integrity of the 
missile during earthquake-induced loading 
conditions, 


20. SAFEGUARD System ~— SPARTAN — Reevalu- 
ation of Environmental Criteria and Stress 
Requirements for Equipment in the 
SPARTAN Launch Station Deflector 
Region — Case 27950-1010, G. N. Zacsek 
and W. R. Sieling, Bell Laboratories 
MFF, June 16, 1971. 
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EMR Vulnerability in Abnormal MSR/PAR 
Environments (U) — Cases 27950-1000 and 
-1010, J. A. Freund, Bell Laboratories 
MFF, August 3, 1973. (SECRET) 


Provides data in answer to the Nuclear 
Weapon System Safety Committee proposal 
to inhibit MSR and PAR radiation when the 
cover of a launch cell containing a missile 
with a war reserve warhead is open for 
entry. 


23. SAFEGUARD System — SPRINT/SPARTAN 


EMR Vulnerability in Abnormal MSR/PAR 
Environments (U) — Cases 27950-1000 and 
-1010, J. A. Freund, Bell Laboratories 
MFF, October 10, 1973. (SECRET) 


Presents data to show that the SPRINT and 
SPARTAN missile subsystems are safe 
under conditions of MSR or PAR RF Inhibit 
Mask control failure. Proposes, there- 
fore, deletion of Rule 9 of the Nuclear 
Weapons Systems Safety committee, which 
would prohibit MSR and PAR radiation 
when the cover of a launch cell containing 
a missile with a war reserve warhead 
section is open. 


24, SPARTAN — Reliability Study of the Burst 
Delay Timer — Case 36294-22, W. J. 
Akstulewicz, Bell Laboratories MFF, 
May 28, 1969. 

Presents results of a reliability study 


performed on the SPARTAN burst delay 
timer design. 


Qualification Tests of the SPARTAN Burst 
Delay Timer — Case 27703-1010, 
J. L. Henry, Bell Laboratories MFF, 
June 13, 1969. 


25. 


Describes the procedures and results of 
qualification tests (operation under ex- 
tremes of temperature, random and sinu- 
soidal vibration, shock, acceleration, 
pressure, and acoustic energy) performed 
on the SPARTAN burst delay timer. 


26. SAFEGUARD System — Evaluation of 
SPARTAN Auxiliary Heating/Cooling 
and Ventilating Unit — Case 27950-1010, 
G. N. Zacsek, C. S. DeSilets, and 
D. F. O'Sullivan, Bell Laboratories MFF, 
April 21, 1972. 
Reviews the capability of a trailer-mounted 
air conditioning unit that is being assem- 
bled by the Army to ventilate a SPARTAN 
cell while personnel are in the cell per- 
forming maintenance operations, Exam- 
ines the compatibility of this unit with the 
launch station's environmental control 
system and its capability to maintain the 
station's temperature and humidity re- 


quirements in accordance with the facility 
criteria, 


Potential Adhesives For Use On Model 115 
ZEUS-NIKE-X Nozzle, McDonnell- 
Douglas Astronautics Company, Report 
No. SM 49189, April 27, 1966. 


27. 


Determines mechanical and physical 
properties of adhesives for bonding nozzle 
liners to steel shells; includes methods 
for evaluation and selection of an adhesive 
system. 


28, Three-Motor Transportation and Handling 
Environmental (THE) Test Program Test 


Results, McDonnell-Douglas Astronautics 
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Company, Interim Report Vol I and H, 
MDC G3876, December 1972, and Final 
Report, MDC G4662, July 1973. 
Details the test plan and results of the 
program which evaluated the capability 


of the SPARTAN motors to survive the 
ground handling environments, 


29. MGS Power Discrete Circuit Operation — 
Case 27703-1010, L. G. Johansson, Bell 
Laboratories MFF, October 2, 1967, 
Presents worst-case output data and de- 
scribes the operation of the Missile Guid- 
ance Set (MGS) power discrete circuit 
under end-of-life condition. Discusses 


and evaluates the effects of radiation on 
either a triggered or untriggered circuit. 


30. Relocation of SPARTAN Strakes and Effect 
Upon Antenna Gain (U), Bell Labora- 
tories Report, September 25, 1965. 
(SECRET-RD) 

Presents the results of an antenna pattern 
measurement program conducted as a 
result of a requirement to relocate the 


aft antenna strakes of the SPARTAN 
missile. 


31. Design and Reliability Considerations for 
Integrated Circuit Operational Amplifiers 
Used in SPRINT/SPARTAN Launch Prep- 
aration Equipments — Cases 27703-1000 
and 27703-1010. F. J. Zgebura, Bell 
Laboratories MFF, May 7, 1970. 
Describes the electrical and reliability 
differences that exist between the two 
basic forms of integrated circuit opera- 
tional amplifiers proposed for use in the 


SPRINT /SPARTAN Launch Preparation 
Equipment. 


32. SPARTAN Hydraulic Control System Review: 
June 6, 1968 — Case 27703-1010, 
E. J. Schuler, Bell Laboratories MFF, 
June 26, 1968. 
Presents a review of problems and de- 


sign changes in the hydraulic control 
system of the SPARTAN missile. 
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33. SPARTAN HPU Vibration Signature Analysis — 


Theoretical Background — Data Handling 
Techniques — Application and Empirical 
Refinement, AiResearch Manufacturing 
Company, Report 72-8442, September 1972. 
Describes the development of the exceed- 
ance curve method of vibration signature 


analysis used for acceptance testing of 
SPARTAN hydraulic power units. 


34, SAFEGUARD System — SPARTAN — The 


Problems of Condensation on the Inner 
Surfaces of the SPARTAN Launch Cell 
Covers — Case 27950-1010, W. R. Sieling, 
Bell Laboratories MFF, August 13, 1970. 


Investigates likelihood of condensation 
forming on the inner surface of the 
SPARTAN launch cell covers and esti- 
mates insulation requirements necessary 
to prevent condensation under worst-case 
conditions. 


35. SAFEGUARD System — SPARTAN — 


SPARTAN Launch Cell Cover Insulation 
(U) — Case 27950-21, Filing Case 27950- 
1010, W. R. Sieling, Bell Laboratories 
MFF, November 24, 1970. 
(CONFIDENTIAL) 

Considers the possibility of completely 
removing the silicone rubber insulation 


from the outer surface of the SPARTAN 
launch cell covers. 


36. SAFEGUARD System — SPARTAN — Effect 


of Decelerator Configuration on Cell 
Cover Reaction Forces — Case 27858- 
1010, E. J. Schuler, Bell Laboratories 
MFF, December 31, 1973. 


Documents a study of the forces and mate- 
rial strengths pertinent to an investigation 
of the cracking of a cell cover frame 
which occurred during the SPARTAN 
M2-34 launch when the cover was operated 
in the fast mode. 


37. SAFEGUARD System — SPRINT/SPARTAN 


Status of EMR Evaluation Program — 
Cases 27950-1000 and 1010, J. A. Freund 
and R. P. Massey, Bell Laboratories 
MFF, May 3, 1974. 
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Summarizes the status of the Electromag- 
netic Radiation (EMR) Test and Analysis 
Programs for the SPRINT and SPARTAN 
subsystems. These programs have com- 
bined the efforts of Bell Laboratories, 
their subcontractors, and government 
agencies. Not all aspects of this EMR 
evaluation had been completed at this 
time. This memorandum provides recom- 
mendations regarding the remaining work 
on a task-by-task basis. 


38. SAFEGUARD/SPARTAN Missile Subsystem 


Effectiveness Engineering Mathematical 
Model (U), McDonnell-Douglas Astro- 
nautics Company, DAC 61926, June 1971. 
(CONFIDENTIAL) 


Presents the quantitative assessment of 
SPARTAN missile subsystem reliability 
and availability, including R&D flight 
reliability history and missile reliability 
growth. 


39. SAFEGUARD System — SPARTAN — Design 


Deficiencies of the Nuclear Ground Shock 
Isolated Launch Rail Uncovered During 
the Dynamic Test at Ileginni — Case 
27950-1010, C. S. DeSilets, Bell Labora- 
tories MFF, June 29, 1972. 


Reviews the design deficiencies in the 
SPARTAN axially isolated launch rail that 
were uncovered during the dynamic test 
performed on a SPARTAN missile and 
launch rail installed in Launch Station 31 
at lleginni. Describes subsequent 
redesign effort required, 


40. SAFEGUARD System — Meck System Test 


Program (U), Bell Laboratories, Report 
4S040R92B, June 1, 1970, Revised 
February 28, 1974. (SECRET) 


Presents requirements and plans for 
SAFEGUARD System prototype testing 
at the system level at the Kwajalein 
Missile Range. 


41. SAFEGUARD System, Progress Report (U), 


Bell Laboratories, January 1975. 
(SECRET) 


This report, one of a series prepared 
for the Army by Bell Laboratories, con- 
tains a summary of the test program at 
Meck. 


42, SAFEGUARD/SPARTAN Missile Subsystem 43. SAFEGUARD System — Review of SPARTAN 


Effectiveness Engineering Mathematical Flights Conducted in the Meck System 
Model Methodology, McDonnell- Douglas Test Program (U) — Case 27950-1010, 
Astronautics Company, SM 52285C, H. G, Idell and J. A. Piccininni, Bell 
August 1971, Laboratories MFF, July 30, 1975, 
Contains the analytical methodology used (SECRET) 

to describe the SPARTAN missile subsys- Describes the results of SPARTAN mis- 
tem effectiveness. The probabilistic sile flights launched during the tests at 
theory and techniques used to analyze re- Meck Island g 


liability and availability are presented, 
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References for Chapter 11 


Data Processing System 


1, SAFEGUARD System — Data Processing Sys- 5. SENTINEL — Results of Availability Study of 
no tem (DPS) — Tactical Software Control Central Logic and Control (CLC) of Mis- 
: Site — MSR DPS and PAR DPS Configura- sile Site Data Processor — Case 27950- 

; tions — System Description, Engineering 2110 (U), R. F. Morra, Bell Laboratories 
ee Support Data Manual DPST-01, Western MFF, February 27, 1969. (SECRET) 
E Electric, May 31, 1973. Results of a study showing that with a 


partitionable system, required availa- 
bility can be achieved by using an on-line 
spare (n + 1 rack) philosophy rather than 
more extensive redundant systems. 


Provides comprehensive coverage of 
theory, operation, and on-line 
maintenance, 


2, DPS-2 Hardware Change Requests — Case 
. : 27703-1500, A. F. McPherson, Bell 
: Laboratories MFF, March 1, 1968. 


6. SENTINEL System — Logic Design Manual, 
G489909, Bell Laboratories, July 1968. 


Contains logic design rules for use in 


ts PINIKE 30 t DPS.2 GGENTINEL / designing the SENTINEL logic to meet 
SAFEGUARD) for all elements of the system operational speed and reliability. 


DPS, with recommendations as to whether 
they should be included in the DPS-2 


design. 7, SAFEGUARD System — Data Processing Sys- 
tem (Tactical Software Control Site) — 
3. SAFEGUARD System — Systems Program- Central Logic and Control Digital Data 
‘ mer's Guide to the SAFEGUARD CLC, Processor — Operation and On-Line 
: Vol 2, Bell Laboratories, SYSPROG- Maintenance, Engineering Support Data 
q CLMV2, Revision 6, June 1, 1974, Manual CLCT 1-11, Western Electric, 


Complete and detailed description of the June 30, 1972. 


CLC and all its component parts, Con- 
tains comprehensive listings of word 
ae structure and organization. 


Comprehensive coverage of theory, 
operation and on-line maintenance, 





\ 4. Patent No. 3, 641,505 — Multiprocessor Com- 8. SENTINEL Processor — System Design 

t puter Adapted for Partitioning into a Specification, L. L. Cochran, Sperry 
: Plurality of Independently Operating Rand — Univac Document U-101956, 

i Systems, issued to W. M. Artz, K. R. April 4, 1968. 

= Cornelius, J. W. Olson, G. R, Signor, and The basic specification to which Univac 
. F. E. Slojkowski, February 8, 1972. soe in the design of the processor 


Patent granted on the multiprocessor 
computer organization as used in 
SAFEGUARD, with capability for par- 
titioning into independent systems. 
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9. A Proof of the Validity of the Proposed Very 
High Speed Multiply Algorithm for the 
NIKE-X Computer, M. R. Steffen, Sperry 
Rand-Univac, Document U- 100652, 
January 14, 1966. 

Discusses a very fast multiply algorithm 


which has since been included in the 
SAFEGUARD Processor design. 


10. Structure and Sequences of the NIKE-X Proc- 
essor Program Control Section — Logic 
Studies, L. F. Delaney, Sperry Rand- 
Univac, Document U-100380, November 
11, 1964, Revised October 26, 1965. 
Describes the theory, structure and 


operational sequences of the program 
control section for the processor. 


11, The Logical Development of the Operand Con- 


trol Unit of the NIKE-X Processor — 
Logic Design, M. J. DeBlauw, Sperry 
Rand-Univac, Document U-100476, 
January 13, 1965. 

Describes the operand control unit for the 


processor, including instructions, memory 
speeds and interfaces characteristics. 


12. SAFEGUARD System — Data Processing 
System (Tactical Software Control Site) — 
Central Logic and Control Program 
Storage — Operation and On-Line Main- 
tenance, Engineering Support Data Manual 
CLCT 2-11, Western Electric, 

February 29, 1972. 


Comprehensive coverage of theory, 
operation and on-line maintenance, 


13. SAFEGUARD System — Data Processing 
System — Variable Store and Fixed Pro- 
gram Store Core Memory System — 
Operation and On-Line Maintenance, 

Vol I, Engineering Support Data Manual 
CLCT 23-11, Lockheed Electronics 
Company, February 4, 1970. 


Comprehensive coverage of theory, 
operation and on-line maintenance, 
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14, SAFEGUARD System — Functional Descrip- 
tion of the Program Store Interface 
Switching Unit — Case 27950-1100, 

R, W. Stout, Bell Laboratories MFF, 
May 16, 1972. 
Theory and operation of the interface 


switching unit that connects a program 
store rack to other parts of the CLC. 


15. SAFEGUARD System — Description of 
Changes Required to Decrease Data Ac- 
cess Time inVS, PS, and T&S Racks — 

_ Case 27950-1100, C. S. Hughes I, Bell 
Laboratories MFF, June 24, 1971. 
A description of ISU changes which take 


advantage of a speed-up in data access 
time of the 500 ns Lockheed core memory, 


16. SAFEGUARD System — Data Processing Sys- 
tem (Tactical Software Control Site) — 
Central Logic and Control Variable Stor- 
age — Operation and On-Line Mainte- 
nance, Engineering Support Data Manual 
CLCT 3-11, Western Electric, 

January 31, 1972. 


Comprehensive coverage of theory, 
operation and on-line maintenance. 


17, SENTINEL System — Description of the 
Variable Store Interface Switching Unit — 
Case 27703-1500, C. S. Hughes I, Bell 
Laboratories MFF, March 11, 1969. 
Theory and operation of the interface 


switching unit that connects a variable 
store rack to other parts of the CLC, 


18, SAFEGUARD System — Data Processing Sys- 
tem (Tactical Software Control Site) — 
Central Logic and Control Input-Output 
Data Controller — Operation and On-Line 
Maintenance, Engineering Support Data 
Manual CLCT 4-11, Western Electric, 
March 31, 1970, Revised March 31, 1972. 


Comprehensive coverage of theory, 
operation and on-line maintenance, 


19. 


20. 


Es 21, 


22. 


Initiation and Termination of I/O on the 


SENTINEL Input/Output Controller — 
Case 27703-1500, J. G. Standley, Bell 
Laboratories MFF, May 22, 1968. 
Comprehensive description for program- 


mers of how to initiate and terminate 
input/output operations. 


. 


SENTINEL System — Input/Output Controller 


Command Word Repertoire — Case 27703- 
1500, J. E. Cullom and R. B, Plunkett I, 
Bell Laboratories MFF, December 1, 1968. 


Describes the theory and operation of the 
SENTINEL IOC, 


SAFEGUARD System — Description of the 


Input/Output Controller Interface Switch- 
ing Unit — Case 27703-2140, C. W. Pugh, 
Bell Laboratories MFF, December 10, 
1969, 

Discussion of theory and operation of the 


ISU that is used to connect the IOC rack 
to other parts of the SAFEGUARD system. 


SAFEGUARD System — Timing Specification 


at the Peripheral Device for the IOC-PD 
Interface — Case 27703-2140, R. B. 
Plunkett II, Bell Laboratories MFF, 
January 6, 1970. 

Interface timing specification which must 


be met by any of 16 peripheral devices 
outside the CLC. 


. 23. SAFEGUARD System — Data Processing Sys- 


tem — Central Logic and Control Timing 
and Status — Operation and On-Line Main- 
tenance, Engineering Support Data Manual 
CLCT 5-11, Bell Laboratories, 

April 15, 1970. 


Comprehensive coverage of theory, 
operation and on-line maintenance. 


&: 24, NIKE-X Proposal for a Timing Generator/ 





Status Unit Which Interconnects to the 
CLC Via an Interface Switching Unit — 


28, 
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Case 27703-1500, J. W. Olson, Bell 
Laboratories MFF, April 6, 1967. 
The first written description of the timing 


ee and status unit to be used in the 
CLC, 


SAFEGUARD — Functional Description of 


the Timing Generator — Case 27950- 
1100, E. C. Ingle, Bell Laboratories 
MFF, October 5, 1971. 


A functional description of the timing 
generator in the timing and status rack. 
This unit is essential in initiating activ- 
ities at a specified time or in recording 
the time at which specified events 
occurred, 


26. SAFEGUARD System — Description of the 


Timing, Status, and Store Transfer Group 
Interface Switching Units — Case 27703- © 
2140, J. W. Hooker, Bell Laboratories 
MFF, June 18, 1969. 

A functional description of the two ISUs 


that connect the T&S rack to the other 
parts of the system. 


SAFEGUARD System — Data Processing Sys- 


tem — Precision Frequency and Time 
Generator (PF&TG) — Operation and On- 
Line Maintenance, Engineering Support 
Data Manual PFTT-11, Western Electric, 
August 15, 1970. 


Comprehensive coverage of theory, 
operation and on-line maintenance. 


SAFEGUARD System — Data Processing 


System (Tactical Software Control 

Site) — Central Logic and Control CLC 
Monitor — Operation and On-Line Main- 
tenance, Engineering Support Data 
Manual CLCT 6-11, Western Electric, 
June 30, 1973. 


Comprehensive coverage of theory, 
operation and on-line maintenance, 


29. SAFEGUARD — Data Processing System — 34. SAFEGUARD System — Data Processing 


Recording Subsystem — Operation and System (TSCS and Tactical Site I&T) ~ 
On-Line Maintenance, Engineering Sup- Maintenance and Diagnostic Subsystem, 
port Data Manual RSST-11, Western System Description and User Guide, Engi- 
Electric, Revised September 29, 1972. neering Support Data Manual M&DT-01, 


Comprehensive coverage of theory, Western Electric, December 31, 1972. 


operation and on-line maintenance, In- 
cludes a list of instruction manuals for 
the commercial or modified commercial 


Comprehensive coverage of theory, 
operation and on-line maintenance, 


equipment, 
: . 35, Patent No, 3, 623,011 — Time-Shared Access 
30. SAFEGUARD System — Data Processing Sys- to Computer Registers, granted to J. S. 
tem (Tactical Software Control Site) — Baynard, Jr., R. L. Coffin, J. E. Cullom, 
Logic to Relay Converter Group — Opera- N. Ehrlich, G. Jones, J. W. Olson and 
tion and On-Line Maintenance, Engineer- D. F. Widman, November 23, 1971. 
ing Support Data Manual LRCT-11, The basic patent issued on the M&D sub- 
Western Electric, December 15, 1972. system as designed into SAFEGUARD. 
Comprehensive coverage of theory, 
operation, and on-line maintenance. 36. SAFEGUARD Data Processing System — 
Maintenance and Diagnostic Processor 
31. SAFEGUARD System — Qualitative/ Controller Functional Description, 
Quantitative Missile Subsystem Safety Case 27950-1500, J. A. Meyer and 
Analysis, Vol 1C, Bell Laboratories, F. B. Torres, October 25, 1971. 
_ February 1, 1975. Describes the M&D processor (CDC-1700) 
A detailed safety study of LRC equipment on which all M&D software is executed. 


Includes a complete description of all 


which contains descriptions of LRC interfaces and component parts. 


operation in each of its modes. 


32, SAFEGUARD System — Data Processing 37. SAFEGUARD System — System Program- 
System (Tactical Software Control Site) — mer's Guide to the M&D Subsystem, 
Data Transmission Controller Group — Vol 5, Bell Laboratories, SYSPROG- 
Operation and On-Line Maintenance, MADV5, Rev 3, September 15, 1974. 


Engineering Support Data Manual DTCT- Contains a comprehensive description of 


s the Maintenance and Diagnostic Subsys- 
11, Western Electric, December 31, 1972. tem, its component parts, and its use 


Comprehensive coverage of theory, with the system. 


operation and on-line maintenance. 

38. SAFEGUARD System — System Readiness 
Verification Subsystem — Operation and 
On-Line Maintenance, Engineering Sup- 
port Data Manual SRVT-11, Western 
Electric, March 15, 1972. 


33. Functional Description of the SAFEGUARD 
Data Transmission Subsystem — Case 
27950-1100, D, K. Dixon and T. F, 
Turnmire, Bell Laboratories MFF, 


July 23, 1971. 

Comprehensive coverage of theory, 
A general functional description of the operation and on-line maintenance. 
data transmission subsystem, which 7 
includes the DTC, 
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39. 


40. 


Greases 


41, 


42. SAFEGUARD System — Tactical Communi- 46, 





i 
Xu 


SAFEGUARD System — Command and Control 43. 


Display Subsystem (TSCS) — Operation 
and On-Line Maintenance, Engineering 
Support Data Manual CCDS-11, Western 
Electric, November 15, 1970. 
Comprehensive coverage of theory, 
operation and on-line maintenance, 


. 


Command and Control Display Subsystem — 
Nuclear Weapons Launch Enable Equip- 44, 


ment, Operation and On-Line Maintenance 
(U), Engineering Support Data Manual 
CCDS4-11, Western Electric, December 
15, 1973. (SECRET) 


Comprehensive coverage of LE system. 


SAFEGUARD System — System Design 


Requirements for Displays and 


Controls (U), 11268704, Vol 1, 45. 


SDRSDCV1@SD##XXXX, and 11268705, 
Vol 2, SDRSDCV2@SD##XXXX, Bell 
Laboratories, June 20, 1974. (SECRET) 
A detailed functional description of the 


displays and controls available in the 
SAFEGUARD System. 


cations Criteria (U), 11,425,721, Revi- 
sion H, Bell Laboratories, May 31, 1974. 
(SECRET) 

A detailed description of all SAFEGUARD 


System communication requirements is 
presented, 
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SAFEGUARD System — Qualitative/ 
Quantitative Missile Subsystem Safety 
Analysis, Vol 1A, Bell Laboratories, 
August 31, 1974, Revised February 1, 
1975. 

A comprehensive safety analysis of the 


Nuclear Employment Authority system is 
presented in this report. 


SAFEGUARD System — NEA System Opera- 
tional Verification Test (U) — Case 
27950-2110, J. Bernardini, N. Ehrlich, 
and W. E. Staubach, Bell Laboratories 
MFF, October 10, 1973. (SECRET) 
The memorandum covers the need for 


and design of the Nuclear Employment 
Authority Recorded-Reproducer. 


SAFEGUARD System — Qualitative/ 
Quantitative Missile Subsystem Safety 
Analysis, Vol 1 and 1B, Bell Labora- 
tories, February 1, 1975. 

A comprehensive safety analysis of the 


Launch Enable system is presented in 
this report. . 


Data Package for NWSSC Design Status 
Review (U), Bell Laboratories, 
October 10, 1973. (SECRET) 


This report contains a complete des- 
cription of the Launch Enable system. 
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ABM 
ABMDA 


ABRES 


ACBIAS 


. ACC 


ACU 
A/D 
ADES 


AEC 
AET 
AF 
AFB 
AFCC 
AFWL 
AGC 
AICBM 
AL 
ALCOR 


ALTAIR 


A 
Antiballistic Missile 


Advanced Ballistic Missile 
Defense Agency 


Advanced Ballistic Reentry 
Systems 


Acceleration Bias 

Area Control Center 
Arithmetic Control Unit 
Analog -to-Digital 


Area Defense Engagement 
Simulation 


Atomic Energy Commission 
Antenna Element Test 

Air Force 

AF Base 

Alternate Fire Control Center 
AF Weapons Laboratory 
Automatic Gain Control 
Anti-ICBM 


Accidental Launch 


‘ARPA-Lincoln Laboratories 


C-Band Observable Radar 


ARPA Long Range Tracking 
and Instrumentation. Radar 


AMC 
AMPL 
AMRAC 


AP 

A/R 

ARA 
ARADCOM 
ARCS 
ARDC 
ARGMA 


ARPA 


ARU 
AT&T 


ATC 
ATES 
AtoD 


ATR 


ATS 


| 
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Army Materiel Command 
Receiver Encoder Level 


Anti-Missile Research 
and Advisory Council 


Ammonium Perchlorate 
Availability/Reliability 
Allowable Reentry Angle 
Army Air Defense Command 
Average RCS 

Air R&D Command 


Army Rocket and Guided 
Missile Agency 


Advanced Research Projects 
Agency 


Automatic Reference Unit 


American Telephone and 
Telegraph Company 


Advanced Technology Center 
Analog TES 
Analog-to-Digital Conversion 
Acceptance Test Requirement 
Active Track Recognition 


Antenna Test Set 


BCB 
BCC 


BF 


BFS < 


BMD 
BMDATC 


BMDC 
BMDOC 
BMDOR 
BMDSCOM 
BMDTP 
BMEWS 


BOD 


BRCS 
BRL 
BRV 
BSA 
BSC 
BSS 


CAL 


CALCOMP 
CAMAR 
CAT 

C&C 


Battery Control Building 


Battery-Centered Cartesian 
Coordinate System 


Burst File 
Beamforming and Steering 
Ballistic Missile Defense 


BMD Advanced Technology 
Center 


BMD Center 

BMD Operations Center 
BMD Operations Room 
BMD Systems Command 
BMD Test Prograni 


Ballistic Missile Early 
Warning System 


Beneficial Occupancy Date 
Building Occupancy Date 
Basic Operating System 
Body RCS 


Ballistic Research Laboratory 


Ballistic RV 

Buffer Store Assembly 
Beam Steering Computer 
Board Steered System 
BMDC Weapons Process 
Ballistic coefficient in lb/ft” 


Cc 


Calspan Corporation (formerly 
Cornell Aeronautical Laboratory) 


Calspan Computer 
Common Aperture MAR 
Catastrophic Test 


Command and Control 


CCB 

CCDS 
ccu 

CDP 

CDR 

CDT 
CENTRAN 
CEP 
CFAR 


CG 


CINCONAD 
CIU 

CLC 

CLSU 


CM 


CMC 
CMDS 


C/N 
CN 
CNWDI 


coc 
COE 
CONAD 


CONOPS 
CONUS 
CP 
CPAF 
CPCC 


Configuration Control Board 
C&C Display Subsystem 
Channel Control Unit 
Central Data Processing 
Critical Design Review 
Conditional Drop Track 
CLC Translator 

Circular Error Probability 
Constant False Alarm Rate 
Center of Gravity 


Commanding General 


Commander-in-Chief of CONAD 


Control Indicator Unit 
Central Logic and Control 
Console Logic Support Unit 


ee Management 


CLC Monitor 
Cheyenne Mountain Complex 


Contractor Maintenance Data 
System 


Clutter-to-Noise ratio 
Normal Force Coefficient 


Critical Nuclear Weapons 
Design Information 


Combat Operations Center 
Corps of Engineers 


Continental Air Defense 
Command 


Continuous Operations Test 
Continental US 

Center of Pressure 

Cost Plus Award Fee 


Central Program Change 
Control 











CPIF 
CPR 


CPU 


CSB 
CSPS 


cT™ 
CTPB 


DARTS 


DCA 
DCDP 
DCDPS 
DCG 


~ DCU 


DD 
DDG 
DDR&E 
DDS 
DEPEX 
DET 
DG 
DICBM 
DKR 
DM 
DOD 
DP 
DPCC 


DPM 


Cost Plus Incentive Fee 


Chinese People's Republic 
(also see PRC) 


Central Processing Unit 
Correction Report 
Cathode Ray Tube 
Control Switch and_Buffer 


Coherent Signal Processor 


-System . 


Contractor Technical Maintenance 


Carboxyl- Terminated 
Polybutadiene 


Continuous Wave 


D 


Debugging Aid for Real-Time 
Systems 


Digital Controlled Attenuator 
Defense Center Data Processor 
Defense Center DPS 

Digital Control Group 

Digital Control Unit 
Discrimination Demonstration 
Digital Data Group 

Director of Defense R&E 
Display Subsystem 

NIKE-X Deployment Study 
Design Evaluation Threat 
Data Gathering 

Depressed ICBM 

Direct Kill Region 

Defense Mode 

Department of Defense 


Data Processor 


' Data Processing and Control 


Computer 


Dispersed Pulse Measurement 


DPO 
DPS 


DPSI 
DPSPR 


DR 


DSS 
DT 
DTC 
DTCA 
DTCG 
DTES 
DTS 
DUX 
DVR 


EBMDC 
ECM 


ECP 


ECS 


ECTS 
ECU 
EDP 
EED 
EGS 
EMP 
EMX 
EOB 
EOD 
EPX 
ERC 


‘Data Processing Officer 


Data Processing System/ 
Subsystem 


DPS Installation Facility 

DPS Performance Requirements 

Detection Radar 
eae Radar 

Display Subsystem 

Design Threat 

Data Transmission Controller 

DTC Adapter 

DTC Group 

Digital TES 

Dynamic Traffic Simulation 

Digital Unit Exerciser 


Digital Video Recorder 


E 
Early BMDC 


Electromagnetic Counter- 
measures 


Engineering Change Proposal 
Environmental Control Station 
ee Control System 
Electrical Circuit Test Set 
Exercise Control Unit 
Exercise Data Processor 
Electro-Explosive Device 
End Game Simulation 
Electromagnetic Pulse 
MSR System Exerciser 
End-Of-Boost phase 
End-Of-Dive phase 
PAR System Exerciser 


Equipment Readiness Center 


ERD 
ERS 
ESK 
ESL 
E-Tape 


ETR = 


EXIT 


FAR 


FCC 


FCS 

FITS 

FL 

FLAM 
FLAR 
FMP 
FOBS 
FORTRAN 
FSC 

FSS 


GE 
GETSS 
GMLEC 


GMLEG 


GMT 
GPDC 
GRC 
GSE 


Equipment Readiness Date 
Extended Range Search 
Environmental Sensor Kit 
Environmental Status Level 
Software Parameter Histories 


Eastern Test Range 


_ Exit Surveillance Region 


F 


False Alarm Rate 


Forward Acquisition Radar 
Face Cartesian Coordinates 
Fire Control Center 

Flight Control Set 

Fault Isolation Test Set 

Fault Locator 

Fault Locating and Monitoring 
Fault Locating and Recording 
Field Measurement Program 
Fractional Orbit Bomb System 
Formula Translator 

Flight Safety Console 

Flight Safety System 

Flight Termination System 


G 


General Electric Company 
GE Time-Sharing System 


Guided Missile Launch Enable 
Controller 


Guided Missile Launch Enable 
Group 


Greenwich Mean Time 
General Purpose Digital Computer 
General Research Corporation 


Ground Support Equipment 


HDR 
HEFU 
HF 


HIA 
HIE 
HIS 
HLT 
HPU 


IBM 


ICBM 
ICLPE 
ICP 
IDA 
IDR 
IEMP 
IF 

1/O 
IOC 


IP 
IPS 
IQD 


iy 


H 


High Data Rate 
High-Energy Firing Unit 
Heating Factor 
Hostile Identification 
HI Authority 
HI Enable 
Honeywell Institute System 
High Level Transmitter 
Hydraulic Pumping Unit 

I 


Intercept Accuracy 


International Business Machines 
Corporation 


Integrated Circuit 


Intercontinental Ballistic 
Missile 


IC Launch Preparation 
Equipment 


IC Package 

Identification 

Institute of Defense Analysis 
Interface Data Reduction 
Internal EMP 

Intermediate Frequency 
Improved MSR 

Input/Output 

Initial Operational Capability 
I/O Controller 

Intercept Point 

IP Selection 

Intercept Quality Data 


Interceptor Response 








rn 


70; 


IRBM 


ISU 
ITP 
ITU 


J-Box 


KMR 


KREMS 


LECS 
LEDM 


LEGG 
LEMC 
LEMR 
LEMT 
LETS 


Intermediate Range Ballistic 
Missile 


Interface Switching Unit 
Installation Test Program 


Interface Transfer Unit 


J 


. 


Junction Box 


- K 


Kill Assessment 


Kwajalein Missile Range 
Known Object Recognition 


Kiernan Reentry Measurement 
Site 


KOR Track 
KOR Track Recognition 


Kwajalein Test Site 


L 


Launch Accuracy 
Launch Area Control 
Local Acquisition Radar 
Low Beta Object 

Logie Control Buffer 
Launch Control Center 
Local Data Processor 
Low Data Rate 

Launch Enable 

LE Coded Switch 


Limited Engineering Development 
Model 


Launch Eject Gas Generator 
LE Message Controller 

LE Message Receiver 

LE Message Transmitter 


LE Transmission Set 


LEU 
LLT 


LO 


LP 
LPE 
LPEC 
LPES 
LPEV 
LQD 
LRC 
LSB 
LSEQ 
LSI 


MA 
MAC 
M&D 
M&DSs 
MAR 
MBGE 


MCC 
MCM 
MDAC 


MDC 


MDI 


MDP 


MDVS 


LE Unit 
Low Level Transmitter 
Launch Order 

i. Oscillator 
Launch Point 
Launch Preparation Equipment 
LPE Compartment 
LPE Set 
LPE Vault 
Launch Quality Data 
Logic-to-Relay Converter 
Least Significant Bit 
Launch Sequencer 


Large-Scale IC 


Minuteman Defense Mode 
Missile Acquisition 
Maintenance Activity Center 
Maintenance and Diagnostic 
M&D System/Subsystem 
Multifunction Array Radar 


Missile-Borne Guidance 
Equipment 


Missile Command Code 
Missile Command Monitor 
McDonnell-Douglas Astronautics 
Company (formerly Douglas 
Aircraft) 

Missile Defense Center 

te Direction Center 
Miss-Distance Indicator 

ee Processor 


Missile Data Processor 


Minuteman Defense Value 
Structure 


MDX 
MEEV 


MFM 
MGS 
MI 
MIL 


MINLCC | 


MIPS 
“MIRV 


MIS 
MISSIM 
Mk-( ) 
MLEA 


MLEC 


MM 
MMC 
MMI 
MMTC 
MN 
MOI 
M-1 


M1-( ) 
MOSAR 
MPR 
MR 
MRA 
MRS 
MRV _ 
MSB 
MSCB 


Miss-Distance Magnitude 


Mechanical and Electrical 
Equipment Vault 


Missile Farm Monitor 
Missile Guidance Set 
MSR Installation Process 
Military 


Minuteman Launch Control 
Center 


Millions of Instructions Per 
Second 


Multiple Independently 
Targeted RV 


Missile Interaction Simulation 
Missile Simulation 
Hostile ICBM 


Missile Launch Equipment 
Adapter 


Missile Launch Equipment 
Controller 


Minuteman 

Martin Marietta Corporation 
Minuteman I 

Missile Monitor Test Console 
Mach Number 

Moment of Inertia 

Programs for MSR testing with 
capability of interception-to- 
space point 


Mission designation 


Modulation Scan Array Radar 


Master Problem Report 
Measurement and Recording 
Management Report Analyst 
Management Reporting System 


' Multiple RV 


Most Significant Bit 
Missile Site Control Building 


MSDP 
MSDPS 


MSR 
MSRDP 
MSRSIM 


MSTP 


MT 

MTR 
MTRACK 
MTS 
MTV 

MW 


NA 
NASA 


NCA 
NCMC 


NEA 
NEARR 


NG 
NICOL 
NOL 
NOP 
NORAD 


NPD 
NPV 
NSA 
NTH 


Missile Site Data Processor 


Missile Site Data Processing 
Subsystem 


Missile Site Radar 
MSR Data Processor 
MSR Simulation 
Meck System Test Program 
fo Site Test Program 
Missile Track 
MT Radar 
MSR MT Simulation 
Mission Test Specification 
Material Test Vehicle 
MSR Weapons Process 
‘< 
Not Applicable 
ae Available 


National Aeronautics and 
Space Administration 


National Command Authority 


NORAD Cheyenne Mountain 
Complex 


ae Employment Authority 
Nuclear Engagement Authority 


Nuclear Employment Authority 
Recorder-Reproducer 


Nitroglycerin 
NIKE-X Compiler Language 
Naval Ordnance Laboratory 
No Operation 


North American Air Defense 
Command 


Normal Path Diagnostic 
N-Puise Validation 
National Security Agency 


Nonthreatening 


NWSSC 


OCU 
f ODDR&E 


OLDR 
ee a 
: OSB 
OSCAR 


RV 
PACA 
PAL 
PAR 
PARDP 
PARSIM 

| PASS 
PAVT 


: PCO 
PCS 
PCU 
PDF 
PDS 

a PEPE 





PFA 
PFOBS 
& P- FOR 
t PF&TG 


(ree 


preere 


Nuclear Weapons System Safety 
Committee 


Oo 


Operand Control Unit 


Office of Director of Defense 
R&E 


Off-Line Data Reduction 
Operating System 
Ordnance Safety Box 


On-Site Configuration Activity 
Reporting 


p 


Kill Probability 
Probability that target is an RV 


Propulsion and Control Assembly 
Parallel Assembly Language 
Perimeter Acquisition Radar 
PAR Data Processor 

PAR Simulation 

Parallel ABM System Simulation 


Product Assurance Verification 
Test 


Polybutadiene Acrylic Acid 
Program Change Order 

Position Capability Surface 
Program Control Unit 

Prototype Development Facility 
Performance Design Specification 


Parallel Element Processing 
Ensemble 


Probability of False Alarm 
Potential FOBS 
Parallel version of FORTRAN 


‘Precision Frequency and Time 


Generator 


PHSD 
PI 
PIN 
PL/1 
PM 
PMR 
POMDA 
POR 
POT 
PP1 
pps 
PPS 


PPTL 


PSL 
PT 
PTV 


PU 


PWRCS 
P/Z 


RADOT 
RANC 


R&D 
R&E 
RCA 
RCS 


Preliminary Hardsite Defense 
PAR Installation Process 
Positive Intrinsic Negative 
Program Language 1 
Preventive Maintenance 
Pacific Missile Range 
Post-Mission Data Analysis 
PAR Object: Recognition 
Purged Object Track 

Pulse Pattern 1 

pulses per second 


Policies, Procedures, and 
Standards 


Parallel Plate Transmission 
Line 


People's Republic of China 
(also see CPR) 


Pulse Repetition Frequency 
Program Store 
Physical Science Laboratory 
PAR Test Process 

ae Track 
Propulsion Test Vehicle 
Processor Unit 
PAR Weapons Process 
Peak Wake RCS 
PAR/SPARTAN 


R 


Recording Automatic Digital 
Optical Tracker 


Refraction Attenuation Noise 
and Clutter 


Research and Development 
Research and Engineering 
Radio Corporation of America 


Radar Cross Section 


RD Restricted Data 


RDT&E Research, Development, Test 
& Evaluation 

REFOBS Reference Object Search 

RF Radio Frequency 

RFCM RF Calibration and Monitoring 

RFTO _ RF Test Order 

RFTR RF Test Request 

RFTS RF Test Set 

RLE Remote Launch Equipment 

RM Measured Missile Range 

RMC Radar Measurement Coordinate 
System 

RMI ~ Range Mark Indicator 

RMP Reentry Measurements Program 

rms root-mean-square 

RMV Reentry Measurements Vehicle 
Predicted Missile Range 

RP Resmooth Program 
Retro- Package 

RPCC Orthogonal Coordinate System 

RRG Radar Return Generator 

RSA Rate Saturation Attack 

RSC Recording Set Controller 

RSs Recording Subsystem 

RTE Real-Time Exerciser 

RTI Range Time Intensity 

RUR Region of Unresolved Replies 

RV Reentry Vehicle 

RVCC Range-Velocity Cartesian 
Coordinates 

$s 
SAC : Strategic Air Command 
SA FCA SAFEGUARD Communications 


Agency 


SA FSCOM 
SAFSEA 


SA FSIM 
SA FSM 
SALT 


SAMSO 


SAMTEC 
SAS 

SBI 

s/C 

sCcD 


sco 
SCVS 


SDF 
SDPL 


SDRDC 
SDRS 
SDVS 


SENSIM 
SES 
SEST 


SET 
SFSD 
SG 
SHAR 


SIDLOB 
SIETP 


SAFEGUARD System Command 
(now called BMDSCOM) 


SAFEGUARD System Evaluation 
Agency 


SA FEGUARD System Simulation 
SAFEGUARD System Manager 


Strategic Arms Limitation 
Treaty 


Space And Missile System 
Organization 


Space And Missile Test Center 
Status Accounting System 
Seconds Before Impact 
Signal-to-Clutter ratio 

Small City Defense 

Software Change Order 

oo Change Order 


SPARTAN Capability Value 
Structure 


Slowdown Filter 


SENTINEL Data Processing 
Laboratory 


‘System Design Requirements for 
Displays and Controls 


SAFEGUARD Data Reduction 
System 


SA FEGUARD Defense Value 
Structure 


SENTINEL System Simulation 
SPRINT Engagement Simulation 


SAFEGUARD System EMP 
Site Test 


Small Endoatmospheric Target 
Southern FOBS Self Defense 
SPRINT Guidance 


System Hardness Assessment 
Report 


Sidelobe Tracking Indicator 


System Integration and Evaluation 
Test Plan 


SIMVAL 


SIS 
SIT 
SLBM 


at) 


SPASIM 


SPO 
SPSIM 


SRV 


SSBO 
SSDSU 


SSDU 
SS-9 
SSP 


SSV 


ST 
STACS 
STAG 


STC 
STM 
STS 
STTF 
STU 


Simulation Validation 

SPRINT Interceptor Response 
SPRINT Intercept Simulation 
Site Information Tape 
Submarine- Launched Ballistic 


Missile 


Signal-to-Noise ratio 
“Symbolic NIKE-X 

(assembly language for CLC) 
Support Operation Center 
SPARTAN Intercept Simulation 


SPARTAN Intercept Subsystem 
Simulation 


Special Projects Office 


SPARTAN Intercept Effective- 
ness Simulation 


Satellite Recognition 
Single RV 

ie Readiness Verification 
Second-Stage Burnout 


System Status Display Support 
Unit 


System Status Display Unit 

Hostile ICBM Booster (USSR) 

Search Signal Processor 

Sequential-State Vector 
a Service Vehicle 

Surveillance Track 

SA FEGUARD Tactical Simulator 


SA FEGUARD Threat Action 
Generator 


Sensitivity Time Control 
Special Test Mission 
System Test Specification 

' Site Threat Trajectory File 


Store Transfer Unit 


STVT 


STVTR 
su 
Sv-( ) 
swoc 


SYSEX 


TA 
TACMAR 
TACMSRSIM 
TACSA FSIM 
TALO 

T&S 
TATCOG 


TBS 
TBU 
TDP 
TES 
TF 
TFBCT 


TGO 
TI 
TIC 
TID 
TIG 
TJH 
T/M 


TMR 
TMRC 


System Technical Verification 
Test 


STVT Requirements 
Status Unit 
SAFEGUARD Vehicle 


SPARTAN Warhead Output 
Contour 


System Exerciser 


T 
Track Acquisition 

Tactical MAR 

Tactical MSR Simulation 
Tactical SAFEGUARD Simulation 
Time After Liftoff 

Timing and Status 


Tri-Agency Technical Coordina- 
tion and Operations Group 


Tape Buffer System 

Tank Breakup 

Target Data Processor 

Tactical Environment Simulation 
Track File 


Tracking Filter Ballistic 
Coefficient Test 


Timing Generator 

Time to Go 

Time of Intercept 

Target Intercept Computer 
Tracking for Identification Data 
Track Initiation and Grouping 
Time of Jethead Ignition 
Telemetry 

T/M Flight Data 

Target Measurements Report 


Technical Maintenance Repair 
Center 


TOD Time Of Day 
TOF TimeOf Flight 
TOO Target Of Opportunity 
TOP Trajectory Obscuration Program 
TOS Tactical Operating System 
= Transmit-Receive 
TR ; 
Trouble Report 
TRADEX — Target Resolution and 
Discrimination Experiments 
Radar 
-TRADOC Training and Doctrine 
Command 
TRM Test Requirements Memorandum 
TRP Telemetry Reduction Program 
TS Technical Specification 
TSA Target Selection Aid 
TSB Temporary Storage Block 
(buffers) 
TSCS Tactical Software Control Site 
TSE Tactical Support Equipment 
TSF Target Selection Function 


TSI(A), (B), (C) Track for SPARTAN Intercept 


TSL 
TSP 
‘TSTS 

TT 
TTR 
TTY 
TUB 
TV 
TVC 


Part A, B, C (tracking intervals) 
Time Since Launch 

Target Selection Process 
Third-Stage Test Set 

Target Track 

Target Tracking Radar 
Teletypewriter 

Trajectory Uncertainty Bound 
Technical Verification 

Thrust Vector Control 
Traveling Wave Tube 

TTY Exchange 


U 


Ultra High Frequency 


vV-10 


UMAB 


UMB 
UOR 
UOV 
UREC 
US 
USSR 


UTL 


vco 
VHF 
VIRADE 
voL 
VPC 

vs 

VSL 
V™ 


WAGC 
WECo 
WG 
WICOR 
WL 
WSMR 
wt 
WTR 
WUSSR 


XPF 


Universal Missile Assembly 
Building 


Universal Missile Building 
User-Oriented Requirement 
User Operational Verification 
Utility Recording 

United States 


Union of Soviet Socialist 
Republics 


Universal Transporter Loader 


Vv 
Voltage-Controlier Oscillator 
Very High Frequency 
Virtual Radar Defense 
Verified Objects List . 
Video Pulse Converter 
Variable Store 
Verification Scheduling List 
Visible Threat Message 


Ww 


Wake AGC 

Western Electric Company 
Gate Width (range) 

Wave Band Correlated 
Wake Length 

White Sands Missile Range 
Wake Track 

Western Test Range 
Western USSR 


X 
Execution Preparation Facility 


. 


Zz 
ZEUS Acquisition Radar 





& 


(rey 


precrimesy 


plese may ee 
Cae ‘ Ye 


Fer 


ere 


Sree 


Pe 


ZIR 
ZMAR 


SPARTAN Interceptor Response - ZOS 


ZEUS Multifunction Array ZSIM 
Radar 


V-11 


Zero Order Software 


SPARTAN Missile Simulator 
Segment of SPASIM 


